Hallo und Willkommen bei tommie-lie's GLScene for insiders ...ähh beginners natürlich... Part 1

Zuerst ein bisschen, was alle Schüler ärgert: Geschichte. GLScene wurde von Mike Lischke (vielen wohl bekannt durch seine GraphicEx-Library für Delphi) entwickelt um eine einfache und sehr flexible Grafikumgebung für Delphi auf OpenGL-Basis zu schaffen. Bei Version 0.5 dann von Eric Grange übernommen und nach OpenSource-Manier auf die SourceForge-Server umgezogen, findet man einen GLScene-Snapshot und interessante Neuigkeiten rund um GLScene (irgendwer verwirklicht immer coole Effekte) unter http://www.glscene.org bzw unter http://glscene.sourceforge.net.
Das Problem am Snapshot ist nur, daß er meist veraltet ist (der aktuellste hat glaub' ich noch ein TGLCanvas-Problem mit (einigen?) nVidia-Grafikkarten und aktiviertem Nebel), da wie bei jedem guten OpenSource-Projekt die meiste Arbeit im CVS-Tree stattfindet. Auslesen (und somit die aktuellste Version erhalten) kann man mit TortoiseCVS recht einfach, die Daten Zugangsdaten finden sich auf der GLScene-Homepage bei den FAQs. Mangels Breitbandinternet (ist doch recht groß, mit Hilfe und Demos) kann ich es nicht hochladen und bereitstellen, aber es lohnt sich wirklich, sich die CVS-Sourcen zu holen, da werden ständig Fehler verbessert und neue Features hinzugefügt.

Die Installation gestaltet sich denkbar einfach, indem man im entsprechenden DelphiX-Verzeichnis (X steht für die benutzte Delphi-Version) das GLSceneX.dpk installiert. Damit der Linker alles findet, empfiehlt es sich vorher unter Toolas -> Environment Options -> Library -> Library Path alle Unterverzeichnisse von [GLScenepath]/Source hinzuzufügen, natürlich einschließlich Source selbst. Soweit die Vorbereitungen, kann also losgehen.

Man findet in der Komponentenbar einen neuen Tab „GLScene“. Richtig, da sind die GLScene-Kompos drin. Nicht überwältigen lassen, vieles braucht man kaum, aber alles ist sinnvoll und man findet sich zurecht.
Einigen wir uns zuerst auf die Namen, damit erspare ich mir Arbeit:

• TGLScene (der gelber Würfel) = GLS
  
• TGLSceneViewer (gelber Würfel mit Kamera davor) = SV
  
• “Scene Editor“ (kommt später) = Scene
  
• “Scene Objects“ im SceneEditor (kommt später) = Objects
  

Ich denke das wär's für's erste.
Fügen wir also eine GLS und einen SV zu unserem projekt hinzu, wie mit jeder Komponente. Die Erfindungsfreudigen haben schon erkannt, daß man letzteren in der Größe verändern kann und vermuten, daß darin die Scene angezeigt wird. Daher empfehle ich einfach mal das Align-Property auf alClient zu setzen...

Per Doppelklick auf das GLS gelangen wir in den Scene Editor. Die Scene ist streng hierarchisch aufgebaut, jedes Objekt kann einen Child haben, und jedes einen Parent. Da jedes Objekt ein eigenes Koordinatensystem besitzt, ist das äußerst praktisch, denn mann kann so andere Objekte an ein bestimmtes Objekt binden, sodaß man nur das eine bewegen muss, um gleichzeitig auch das andere zu bewegen. Die Bedienung ist einfach, aber für einen absolut Ungeübten leicht verwirrend. Man hat zwei Buttons, die Objekte hinzufügen (dritter und vierter von links, in der Buttonbar), von denen jeweils einer immer ausgegraut ist. Hinzugefügt werden die Objekte immer als Child des aktuell angewählten Objektes in der Baumstruktur; sobald ein Objekt hinzugefügt wurde, wird es automatisch ausgewählt (hier entsteht meist Verwirrung, weil man immer Childs hinzufügt). Besagter linker Button ist nur aktiv, wenn die Kategorie „Cameras“ ausgewählt ist. Also auswählen, Button drücken und sich über die Kamera freuen (man kann übrigens mehrere Kameras in einer Scene haben, dann kann man schnell und einfach zwischen mehreren Winkeln wechseln). Der andere Button ist nur aktiv, wenn die Kategorie „Scene Objects“ ausgewählt ist und führt zu einer Reihe Untermenüs, von denen wir jedoch vorerst nur „Basic Gemoetry“ brauchen werden (wer Lust hat kann trotzdem die anderen Menüs erforschen, das eine oder andere werden wir später noch brauchen). Also eine LightSource und einen Cube (ersteres aus dem Root, zweiteres aus der Gemoetry-Reihe) hinzugefügt und drauf geachtet, daß beide Childs von den „Scene Objects“ sind, und nicht der Cube zum Child der LightSource wird.
Szene also schon fertig? Nö.
Es ist immer gut, die Lichtquelle aus Richtung der Kamera kommen zu lassen (so sieht man am meisten), also per Drag&Drop die Lichtquelle zum Child der Kamera gemacht (ja, D&D funktioniert über die Objects-Cameras-Grenze hinaus). Wie bereits erwähnt hat jedes Objekt ein eigenes Koordinatensystem. Die Position wird für jedes Objekt mit dem Position-Property in Fließkommawerten angegeben. Da jedes neu hinzugefügte Objekt als Standardeinstellung immer auf (0,0,0) gestellt ist, befindet sich die Lichtquelle nun also auf Position (0,0,0), aber im Koordinatensystem der Kamera. Diese befindet sich auch auf (0,0,0), was zufällig dazu führt, daß die Kamerakoordinaten mit den Weltkoordinaten (also dem Koordinatensystem des „Scene Objects“-Objekt in der Baumstruktur) übereinstimmen. Das ändern wir aber schnell, indem wir das Position-Property der Kamera auf (0,2,-5) stellen (entweder per Dialog über die drei Punkte im OI, oder indem man auf das Plus klickt). Jetzt befindet sich in Weltkoordinaten die Lichtquelle ebenfalls auf (0,2,-5), obwohl deren Position-Property immer noch (0,0,0) anzeigt, aber wir haben ja mit der Kamera auch deren Koordinatensystem verschoben. So, Koordinatensysteme also besprochen.

Woher soll die Kamera jetzt noch wissen, wohin sie schauen soll? Klar, auf den Cube, aber wie sagt man ihr das? Also das TargetObject-Property der Kamera auf unseren GLCube1 gestellt.
Problem, man sieht nichts im SV, selbst nach einem Druck auf F9. Wie gesagt, man kann mehrere Kameras haben, also weiß der SV nicht automatisch, welche er nehmen soll. Das teilt man ihm aber über das Camera-Property mit, das wir auf GLCmaera1 setzen.

Siehe da, man sieht was im SV. Und schon kommen wir zum größten Vorteil von GLScene: Man hat eine vollständige Preview zur Designtime aller statischen Dinge der Scene (also Partikel und Bewegungen werden nicht berechnet, würde ja auch vom Programmieren ablenken).
Ohne das Programm zu kompilieren sehen wir also schon unseren Würfel, was durchaus praktisch sein kann, wenn man komplexere statische Anordnungen hat und nicht jedesmal zum Überprüfen kompilieren will.
Grauer Würfel auf grauem Hintergrund macht sich aber nicht sehr gut. Dafür gibt es das Buffer-Property vom SV. Dort kann man neben Farbtiefe, AA, Lighting und dergleichen auch den Background angeben. Dort wählen wir erstmal Schwarz (oder eine andere schöne Farbe, die einem gefällt (wie bei jeder Tcolor-Variable kann man auch hier Hexadezimalzahlen nach dem Typ $00bbggrr angeben)).

Schon sieht man den Würfel besser (oder je nach Farbwahl auch schlechter ). Aber wir wollen auch bunte Würfel haben? Dafür gibt es für jedes sichtbare Objekt in der Szene ein Material-Property. Also wieder Doppelklick auf die GLS um in den Editor zu gelangen und den Würfel auswählen. Da wir FaceCulling nicht brauchen, wird es überischtlicher sein auf die drei Punkte zu klicken, wodurch sich das Fenster „Material Editor“ öffnet.
Die 4 Slider dürften an etwas wie RGBA aus bekannten Zeichenprogrammen erinnern. Die 4 Tabs sind schon interessanter (sind aber nicht GLScene-spezifisch sondern bei den meisten 3D-Modellern auch so):

1. „Ambient“ beschreibt die Farbe des Objektes im Umgebungslicht, also quasi die Farbe der Schatten. Bis auf Ausnahmen bei besonderen Materialien (wie farbiges Glas oder andere, besonders schattierende Sachen) ist das der gleiche Wert wie „Diffuse“.
   
2. Wobei wir auch schon beim nächsten Tab sind. Diffuse ist die eigentliche Farbe des Objektes, in rein weißem licht (oder bei deaktiverten Shadern, je nach Wahl).
   
3. „Emission“ ist die Farbe des Lichtes, das das Objekt selber abstrahlt. Die Farbe ist also unabhängig von Lichtquellen und kann zum Beispiel bei glühenden Objekten verwendet werden, wie Lava oder was anderes, was im Dunkeln leuchtet. Allerdings beeinflußt dieses emissive Light nicht die Shader anderer Objekte. Ein weißer Würfel neben einem grün leuchtenden bleibt also weiterhin weiß.
   
4. „Specular“ letztendlich ist die Farbe der Lichtreflexionen auf der Oberfläche. Kann man zum Beispiel dazu benutzen, farbiges Licht zu simulieren, sieht aber bei Materialien wie Kupfer, Perlmutt und Gold einfach nur besser aus
   Um was zu sehen muss allerdings die Lichtquelle geändert werden. Mehr dazu später. Wenn's also nicht glänzt, Geduld haben.
   

Der Slider Shininess bestimmt die Rauhigkeit des Objektes. Je glatter es ist (0), desto mehr wird reflektiert (in der Preview gut zu sehen. 32 ist ein relativ guter Wert um den Sinn des Ganzen zu erkennen, aber es hängt natürlich vom gewünschten Material ab, was die beste Einstellung ist.

Dann gibt es noch den Blending Mode. Der ist recht einfach erklärt:

• bmOpaque = kein Blending, Flächen sind nicht transparent (Blending <> Shading )
  
• bmTransparency = normales Alpha Blending, Flächen werden gemäß angegebenem Alpha-Wert in den Hintergrund geblendet.
  
• bmAdditive = kein wirkliches Blending, sondern die Farbwerte werden zum Hintergrund hinzuaddiert. Also eine Art „statische Transparenz mit Farbverfälschung“. Bei normalen Materials kenne ich keine Anwendungszwecke, also keine Beispiele.

Da jede Fläche ein vorne und ein hinten hat, gibt's ganz oben auch noch die Buttons Front und Back. Aber da haben noch einige Einstellungen am SV und am FaceCulling ihre Finger im Spiel, die Rückseite ist also nicht ohne weiteres sichtbar (mit den Standardeinstellungen). Gleich daneben findet man die äußerst wichtigen Textures.
Dort ist es wesentlich überischtlicher., allerdings wegen stetiger Weiterentwicklung auch ein wenig veralteter. Bei Image ist zum Beispiel nichts zu gebrauchen außer die Einstellung PicFile. Das veranlasst eine reine Pfadangabe zum Bild, das Bild an sich wird vollständig zur Laufzeit geladen. Lässt man die Combobox in weiser Voraussicht leer und klickt nur auf die Ellipsis, erhält man vom Effekt her ein Persistent, was genauso funktioniert wie Images aus dem Timage von Delphi, also die Bilddaten werden in die DFM-Datei geschrieben und auch von dort geladen (Bild selbst muss nicht anwesend sein, wenn man das Programm ausführt). Die restlichen Einstellungen erzeugen allesamt Fehler, weil bei GLScene mehr Wert auf Dynamik gelegt wurde, da bei den meisten Anwendungen sowieso kaum was statisch ist und dafür die genannten Optionen reichen. Will man mehr, muss man das Material-Peroperty im OI manuell bearbeiten, und zwar dort das Property Texture (dort wiederum ImageClassName) im Speziellen. Daher hier eine vollständige Liste der möglichen Einstellungen im OI:

• Blank Image = ein Image ohne Inhalt, dafür konzipiert dynamischen Inhalt während der aufzeit zu erzeugen
  
• Persistent Image = Ressourcenimage wie Timage von Delphi
  
• PicFile Image = Image ohne Inhalt, wird aus Datei geladen, wenn es benötigt wird
  
• CubeMap Image = Image-Klasse für Cubemaps, also 6 Bilder, die Reflektionen realistischer erscheinen lassen sollen
  
• Procedural Noise = ein Image für Perlin Noise (www.freespace.virgin...models/m_perlin.htm)
  

Beim Rest sieht es leider ähnlich aus: die Form ist relativ veraltet. Daher empfehle ich spätestens hier, den OI zu Rate zu ziehen, um mir besser folgen zu können. Das meiste dürfte selbsterklärend sein, daher hier nur eine Liste:

1. Compression
   
   
   • Default = globale Texturkompression (kann man irgendwo bei den Windows-Treibern einstellen, manchmal...
     
   • None = keine Texturkompression (nicht zu empfehlen: langsamer als nötig)
     
   • Standard = Standardkomprimierung, mittlere Qualität, mittlere Performance (für Normalverbraucher gut genug)
     
   • HighQuality = hohe Texturqualität, langsam, für Perfektionisten
     
   • HighSpeed = hohe Performance, aber nicht so gute Texturen, für weit entfernte Objekte besser geeignet
   
   
   
2. FilteringQuality
   
   
   • Isotropic = bilineares Texturfiltering, schneller, aber bei wirklich schrägen Flächen (Gänge, halboffene Türen) auch schlechter
     
   • Anisotropic = trilineares Filtering, langsamer (heute immer noch? Ich kenn die Whitepapers der Radeon 98er noch nicht auswendig ), aber auch besser bei extremen Schrägen
   
   
   
3. ImageAlpha
   
   
   • Default : Benutzt, falls vorhanden, Alphakanal aus dem bild (z.B. von 'ner Targe Truevision-Textur)
     
   • AlphaFromIntensity : Alpha wird von der Farbeintensität geschätzt, je heller die Farbe, desto deckender ist sie nachher
     
   • SuperBlackTransparent : ein bisschen GIF-Like, Alle Pixel, die schwarz sind, sind 100% transparent, alle anderen 0% (nix Abstufung)
     
   • Luminance : Leuchtkraft wird berechnet (anhand der Umgebung) und mit den RGB- und Alpha-Werten verrechnet
     
   • LuminanceSqrt : Das gleiche, nur mit wird vor dem Verrechnen die Wurzel vom errechneten Wert gezogen.
     
   • Opaque : Kein Alpha, also vollständig deckend
     
   • TopLeftPointColorTransparent : die Englischgenies wissen's bereits, Die Farbe, die der obere, linke Punkt hat, ist transparent, der Rest nicht
   
   
   
4. MagFilter (Fitler für Vergrößerung)
   
   
   • Linear = Pixelfarben werden von ihren 4 Nachbarn berechnet
     
   • Nearest = Pixelfarben werden nach ihrer Gesamt-Umgebung berechnet (einschließlich Intensität usw)
   
   
   
5. MappingMode = hat was zu tun mit der Berechnung automatischer Texturpositionen, mehr weiß ich leider auch nicht (Grafiker, bitte melde dich)
   
   
6. MappingSCoordinates = Mappingkoordinaten der S-Achse (keine Ahnung, was die S-Achse ist, wieder irgendwelche Grafiker hier?)
   
7. MappingTCoorinates = Das gleiche wie MappingsCoordinates, nur für die T-Achse
   
   
8. MinFilter (Filter für Verkleinerung)
   
   
   • Nearest = Umliegende Pixel werden benutzt um neue Pixelfarben zu bestimmen (beste Wahl)
     
   • Linear = die 4 benachbarten Pixel werden verwendet, um neue Pixelfarbe zu berechnen (schneller, kann aber zu Moiré-Mustern oder dergleichen führen)
     
   • NearestMipmapNearest, MiLinearMipmapNearest, miNearestMipmapLinear, miLinearMipmapLinear = Ähnlich den anderen, nur werden die entsprechenden MiMaps (der gleichen Größe wie das zu berechnende) gesucht (entweder mit Linear oder Nearest) und dann aus diesen Referenz-MipMaps die Pixel geholt und wieder mit Linear oder Nearest die endgültige Pixelfarbe berechnet. Benutzt also größere Referenzblöcke und ist deswegen nicht für sehr feine Strukturen geeignet, kann aber bei extrem groben, regelmäßigen Strukturen schneller sein.
   
   
   
9. TextureFormat (Texturformate, einige Karten kommen mit einigen Formaten besser zurecht, meist lohnt es sich aber einfach nicht, für ein 16-bit-Bitmap eine 32-bit-Textur zu benutzen (höherer Speicherbedarf))
   
   
   • Default : globales Standardformat (vom Treiber)
     
   • RGB : 24-bit RGB, 8 bits pro Kanal
     
   • RGBA : 32-bit RGBA, 8 bits pro Kanal
     
   • RGB16 : 16-bit RGB, 5 bits pro Kanal
     
   • RGBA16 : 16-bit RGBA, 4 bits pro Kanal
     
   • Alpha : 8 bits reiner Alpha-Kanal (keine Farbe, nur Durchsichtig oder nicht )
     
   • Luminance : 8-bit reine Lumineszenz.
     
   • LuminanceAlpha : 16-bit Lumineszenz und Alpha, 8 bits pro Kanal
     
   • Intensity : 8-bit reine Intensität
   
   
   
10. TextureMode
    
    
    • Decal = Farbwerte werden mit der Textur verrechnet, scheinen also durch (aber nur, wenn ImageAlpha nicht Opaque ist und das TexturFormat einen Alpha-Kanal beinhaltet (falls ImageAlpha = Default ist, muss natürlich auch ein Alpha-Kanal im Bild sein ))
      
    • Modulate = Farben werden vollständig immer mit der Textur verrechnet, egal ob sie einen Alpha-Kanal enthält oder nicht
      
    • Blend = Textur wird in die Farbe eingeblendet, also die Intensität der Farben wird beibehalten (kann u.A. dazu verwendet werden, Farben in Texturen zu verfälschen)
      
    • Replace = Farben werden vollständig durch die Textur ersetzt
    
    
    
11. TextureWrap = Auch hier weiß ich nicht genau, was es ist. Scheint was mit den ominösen T- und S-Koordinaten zu tun zu haben.

So, das war's schon an Textureinstellungen. Ein Fehler über den viele häufig stolpern ist das Disabled-Property, das sich im Material Editor als Häkchen bemerkbar macht. Da das standardmäßig aktiviert ist (Disabled = True, also Enabled = False...), sieht man nichts von der schönen runtergeladenen, oder nicht so schönen selbstgemalten Textur .

Der OI offenbart außerhalb der Texturen, nur im Material-Property aber noch weitere Eigenschaften, die man im MaterialEditor nicht findet, weil sie einfach nicht üblich sind. Manchmal sind sie aber ganz praktisch (vor allem für Demo-Zwecke), daher hier die fehlenden:

1. FaceCull
   
   
   • BufferDefault = Standardeinstellung aus dem Buffer-Property vom SV
     
   • Cull = dieses Objekt wird auf jeden Fall einem Flächentest unterzogen
     
   • NoCull = dieses Objekt wird nie einem Flächentest unterzogen (selbst wenn der SV was anderes sagt)
   
   
2. MaterialOptions
   
   
   • IgnoreFog = wenn Nebel da ist, beeinträchtigt er dieses Objekt nicht
     
   • IgnoreLighting = Für dieses Objekt scheint keine Sonne...

Die Geschichten um die MaterialLibraries lasse ich jetzt mal weg, weil das eher Sachen sind, die man zwar alltäglich braucht, einem Anfänger aber nur verwirren würden.
In den Front- und Back-Peroperties gibt es noch eine Kleinigkeit, die im MaterialEditor nicht vorkommt: der PolygonMode. Was das ist, könnt ihr selbst rausfinden


Da man etwas am besten lernt, wenn man es tut, solltet ihr jetzt einfach an den Material-Einstellungen spielen. Was vorher nicht so klar war, wird dann vielleicht klarer.




Jetzt haben wir also unseren bunten, bemalten, wie auch immer gearteten Würfel vor einem schwarzen Hintergrund.
Why only one, if we could have two of 'em? Einige haben's vielleicht schon gemacht, aber für alle anderen: man kann durchaus mehr als ein Objekt in einer Szene haben.
Also wieder die Szene geöffnet und ein paar weitere Objekte hinzugeklickt. Position und Material nach Wahl geändert. Man kann auch andere Objekte als Würfel nehmen. Alle dreidimensionalen Objekte (Planes, Lines und Points also ausgeschlossen) haben Properties wie Radius, Height/Width/Depth oder die entsprechenden Äquivalente für die geometrische Figur (naja, ganz ohne Mathe kommen wir nicht aus...). Damit kann man, genau, die Größe der Objekte bestimmen. Die in irgendwie rund gearteten Objekte haben zusätzlich noch Slices und Stacks. Das sind die Anzahl an Stücken, aus denen das Gebilde zusammengesetzt ist, Slices in der Horizontalen, Stacks in der Vertikalen. Mit anderen Worten, man kann damit die Genauigkeit der runden Objekte besitmmen. Ein rundes Objekt muss nämlich wie alle anderen auch aus Polygonen zusammengesetzt werden. Eine Kugel ist also nie eine Kugel, sondern ein dreidimensionaler Körper mit vielen Ecken. Hat er wenig (z.B. Stacks und Slices auf 5), ist es wenig Kugelförmig, hat aber auch seinen gewissen Character. Die Standardeinstellungen für jedes Objekt sind so gewählt, daß sie einigermaßen Rund sind, allerdings sieht man bei Kugeln gerade beim Shaing viele Kanten. Je höher man also solche Einstellungen wählt, desto runder wird die Kugel, aber desto größer ist auch der Rechenaufwand. Daher sollte man bei allen Einstellungen, die Effekte und Genauigkeit genau bedenken, ob man wirklich so große Genauigkeit braucht, sonst werden bei großen Szenen die Grafikkarten ganz schnell schlapp machen.



Jetzt hab' ich erstmal keine Lust weiterzuschreiben und warte auf Feedback. Die ganzen im Text versprochenen Dinge werden natürlich nachgereicht, aber ihr könnt ja eine gewünschte Reihenfolge vorschlagen (jetzt wisst ihr ja, was es noch gibt).
Bei Fragen und Hinweisen stehe ich natürlich per Mail oder PN zur Verfügung.

Prima! Ich wäre dann soweit für die nächste Runde. Konnte mir zwar natürlich nicht alles merken, aber man kann ja immer mal wieder nachlesen. Der Stil gefällt mir, wenn Du so weiter machst, wie Du angefangen hast, wird es wirklich prima!

Jo, ich arbeite grad' an den anderen Properties der Objekte. Da morgen schulfrei ist, ist es dann vielleicht schon fertig, wenn nix dazwischen kommt.

Ihr dürft übrigens ruhig fragen, wenn was nicht ganz klar ist

So, Fortsetzung:
Es fehlen noch einige Properties vom TGLSceneObject (dem Ancestor der meisten Szenenobjekte), die nichts mit Material zu tun haben.
Da wären zunächst die Behaviours. Behaviours sind statische Verhalten (surprise *g*), die in jedem Frame vom Cadencer (vorerst reicht es zu wissen, daß das Ding ein Progress-Event hat, das für Bewegungen benutzt wird) berechnet werden, wie zum Beispiel statische Rotation (einschließlich Masse/Beschleunigungs-Dämpfung), oder Sound Emitter (für 3D-Sound via Fmod oder BASS). Zu den Behaviours kommen wir später, wenn wir auch zum Cadencer kommen, und zwar bei den Bewegungen.

Direction steht in engem Zusammenhang zu Up. Beides sind zwei Vektoren, deren Koordinaten zusammen nicht mehr als 1 oder nicht weniger als -1 ergeben. Direction bezeichnet die Orientierung des Objektes, macht bei Kugeln nicht viel Sinn, kann aber bei Sachen wie Zylindern oder Arrows (wer's nicht kennt, einfach zur Szene hinzufügen und gucken) hilfreich sein. Up ist die Richtung der Oberseite und steht senkrecht zu Direction (daher beeinflussen sich die Werte gegenseitig, wenn man sie ändert). Beide Vektoren geben den Bewegungsfunktionen Move und Lift die Strecke vor, aber auch dazu kommen wir bei den Bewegungen. Der Aspekt der Orientierung ist vorerst der wichtigste, wobei nicht nur das Mesh an sich gedreht wird, sondern auch das Koordinatensystem des Objektes, Childobjekte werden also entsprechend um das Objekt mitgedreht.

Effects kann Effekte enthalten. Jedes Objekt in der Szene hat dieses Property um Sachen wie Partikelmanager, Explosionseffekte usw. zu verwalten.

NormalDirection legt die Ausrichtung der Flächennormalen der Seiten fest. Das beeinflusst das Lighting aber auch vor allem das Rendering der Flächen (mehr dazu siehe unten, „FaceCulling“) der Flächen. So wird zum Beispiel bei einem großen Würfel mit einer Lichtquelle innerhalb des Würfels, die Innenseiten (BackFace) nur dann gelightet, wenn die Normalen auch nach Innen zeigen, dafür wird dann aber die Außenseite nicht mehr beleuchtet, sondern bedarf einer würfelexternen Lichtquelle.

Mit ObjectSorting wird es wieder richtig interessant. Die Reihenfolge, in der Objekte gezeichnet werden, bestimmt letztendlich ihr aussehen, wenn sie Transparent sind. Es gibt die Möglichkeit, das ObjectSorting auch ganz auszuschalten, dann bestimmt die Reihenfolge in der Scene wie die Objekte gerendert werden. Um ein Objekt innerhalb seines Parents nach oben (zuerst gerendert) und nach unten (zuletzt gerendert) kann man im Scene Editor die Händchen (zweiter und dritter Button von rechts) benutzen. Dabei ist dieses Property, weil es nur zum Objekt gehört, objektgebunden. Die Einstellung gilt also nur für dieses eine Objekt. Für globale Einstellungen gibt es die Properties der GLS.
Die Möglichkeiten sind:

• Inherited = benutzt die Einstellungen des Parents für Sorting
  
• None = kein Sorting, Objekt wird entsprechend seiner Position in der „Rangliste“ der Scene gerendert
  
• RenderBlendedLast = Zuerst werden alle Objekte gerendert, die Alpha = 1 sind, und zwar entsprechend ihre Ranglistenposition. Danach werden die Objekte, die geblended werden müssen, sortiert (farthest first) und gerendert.
  
• RenderFarthestFirst = Objekte werden nach ihrer Entfernung zur Kamera gerendert, die weitesten zuerst.

FarthestFirst ist bis auf speziell gewünschte Phänomene den anderen vorzuziehen, weil nur so immer realistische Transparenzeffekte zustande kommen, allerdings ist das auch am langsamsten, weil immer alle Objekte sortiert werden. Wenn die Szene sowieso schon gut sortiert ist oder es auf winzige Details nicht ankommt und die Geschwindigkeit/Effizienz im Vordergrund steht, ist BlendedLast die bessere Wahl.

Viele Objekte (alle bei denen es Sinn macht), haben ein Parts-Property. Damit werden bestimmte Seitenflächen an- und ausgeschaltet. Bei einem Cube kann man zum beispiel jede beliebige der 6 Seiten entfernen, wobei die Würfelinnenseite sichtbar wird (BackFace).

Die Properties PitchAngle, RollAngle und TurnAngle sind ein Wrapper für die Properties Direction und Up. Bei ihnen gibt man anstatt einem Vektor einen Winkel an, und zwar in Grad. Pitch neigt das Objekt um die X-Achse, Roll rollt es um die Z-Achse und Turn dreht es um die Y-Achse, wie man in jedem zweitklassigen Englisch-Deutsch-Wörterbuch nachschlagen kann.

Scale skaliert das Koordinatensystem dieses Objektes (und somit auch das seiner Children) in die entsprechenden Richtungen um den entsprechenden Faktor (entspricht den angegeben werten *g*). Bewirkt zwar eine Vergrößerung der Objektes, sollte aber nicht zum reinen Width/Height/Depth/Radius-Ersatz dienen.

ShowAxes ist besonders für's Debugging interessant. Damit werden die 3 Achsen angezeigt, die sich im Koordinatenursprung des Objektes (überlicherweise der Mittelpunkt, unregelmäßig geformte Meshes mal ausgenommen) treffen. X ist rot, Y grün und Z blau.

Tag und TagFloat sind aus den Delphi-Komponenten bekannt, wobei TagFloat ein Single-Fließkommawert ist.

Der TransformationMode bestimmt das Koordinatensystem, daß beim Transformieren (z.B. beim Drehen) benutzt wird. Wenn das lokale System benutzt wird, verhält sich das Objekt wie gewohnt entsprechendseiner eigenen Achsen, wie sie von ShowAxes angezeigt werden. Bei tmParentNoPos wird das Koordinatensystem des Parents benutzt (falls kein Parent vorhanden das lokale), die Position wird dabei nicht verändert (Der Ursprung liegt immer noch im Objekt selbst, nur die Achsen sind entsprechend transformiert). Bei tmParentWithPos wird die Position mitverschoben. Allerdings weiß ich nicht nach welchem System, da die Dokumentation hier nicht sehr weit reicht und ich noch keinen Zusammenhang entdeckt habe. Gebäruchlich werden wohl nur Local und ParentNoPos sein.

VisibilityCulling legt fest, wann Objekte wirklich gerendert werden und wann nicht. Objekte sieht man ja nur, wenn sie innerhalb des Sichtbereiches der Kamera sind, müssen also nicht gerendert werden, wenn sie hinter der Kamera sind oder von anderen Objekten vollständig verdeckt werden. Daher kann man durch Drehen dieser Einstellung eiiges an Performance herausholen, wenn man Szenen mit sehr vielen Objekten hat. Bei TBR-Karten (bspw. Den Kyro-Serien von PowerVR) kann es manchmal auch sinnvoll sein, das Culling vollständig der Karte zu überlassen, denn die Karten haben meist bessere Methoden (wie gesagt, Tile Based Rendering...). Bei T&L-Boards sieht es ähnlich aus, hier epfiehlt es sich aber nur bei großen Szenen mitvielen statischen Objekten (zum Beispiel technischen Darstellungen, die nicht viel gedreht werden).

• Inherited = benutzt wie Einstellungen des Parents. Für Objekte im Root der Szene ist der Standard dafür die Einstellung vcNone!
  
• None = kein Culling, das Objekt wird immer gezeichnet.
  
• ObjectBased = Jedes Objekt wird einzeln überprüft. Die Childs des Objektes werden nicht beeinträchtigt, also extra geprüft.
  
• Hierarchical = Das Culling erfolgt nach hierarchischer Ordnung. Ist ein Parent nicht gerendert, werden alle Childs ebenfalls nicht gerendert, egal was deren Einstellung ist. Hier kann es manchmal zu Problemen kommen, wenn man die relativen Positionen der Childs so groß hat, das Der Parent hinter der Kamera ist, während das Child vor ihr liegt.

Der Rest dürfte eigentlich klar sein. Mit Name kann man im Code auf die Objekte zugreifen (und sich natürlich einen Monat später besser dran erinnern, was die Sphere da zu suchen hat ) und Visible schaltet die Objekte an und aus.



So.Es wäre natürlich Schwachsinn, die ganzen Einstellungen wie VC und Sorting einzeln für jedes Objekt zu erzeugen, vor allem wenn man sehr viele hat. Deswegen kann man das ganze praktischerweise auch global für die gesamte Szene festelgen. Dafür gibt es die VisibilityCulling- und ObjectSorting-Properties der TGLScene. Die Bedeutung ist heir die gleiche, nur daß VC auf Inherited hier das Culling vollständig ausschaltet, zumindest für alle Objekte der Szene die ebenfalsl auf Inherited stehen.


Natürlich gibt es noch viele weitere Specials, die teilweise nur auf neueren Grafikkarten laufen. Diese beeinflussen aber nicht die Szene selbst, sondern eher die Art und Weise wie sie gezeichnet wird. Deswegen haben sie in der Szene nichts zu suchen und sind im SV zu finden. Zuerst sei da das Vsync zu nennen. Dabei wird entweder der Refresh an das Sync-Signal des Bildschirms gekoppelt und entsprechend genauer sieht das Bild aus. Allerdings kann es bei einigen Grafikkarten zu enormen Leistungseinbußen führen (zum Beispiel bei meiner ). Einige Grafikkartentreiber können das Bild auch gar nicht Syncen, weil die erforderliche OpenGL-Extension (WGL_EXT_swap_control) fehlt. Ideal ist es, diese Einstellung immer den Endanwender übernehmen zu lassen, denn einige Grafikkarten machen's lieber mit, andere ohne...

Die restlichen Einstellungen erinnern stark an die Üblichen TWinControl-Properties und haben auch die gleiche Bedeutung wie dort. Aber halt, da gibt's ja noch den Buffer, in dem wir schon den Hintergrund eingefärbt haben.
AntiAliasing stellt, wie der Name schon sagt, den AA-Mode ein. Default nimmt die Standard-Einstellung aus den Treibern, 2x verdoppelt einen Pixel, 4x macht 4 draus, HQ ist jeweils die langsamere aber genauere Implementation des AA-Algorithmus' und None schaltet FSAA schließlich ganz aus.

DepthPrecision gibt die Größe des Z-Buffers an, bestimmt also wie genau Entfernungen berechnet werden. Der Standard ist immer der höchstmögliche Wert.
DepthTest legt fest, ob Objekte entsprechend dem ObjectSorting sortiert werden sollen. Ist es disabled, werdn Objekte, die zuletzt gerendert werden, immer alle anderen Objekte überlappen. Dabei zählen auch einzelne Polygone als Objekt. Normalerweise sollte dieses Property also immer enabled sein.

FaceCulling ist ähnlich wie VisibilityCulling, jedoch für einzelne Flächen. Jedes Objekt hat ja ein Property für die NormalDirection, das die Richtung der Normalen angibt. Ist das FaceCulling aktiviert, werden nur Flächen gerendert, die zum Betrachter zeigen. Rückseiten von Objekten werden also nicht mehr gerendert. Der HiddenFaceRemoval-Algorithmus ist relativ schnell, macht also durchaus Sinn, wenn man Objekte mit Vielen Seiten hat, die nicht gezeichnet werden müssen (Meshes, Kugeln, ...).

Lighting und ShadeModel dürften aus den meisten 3D-Modellern bekannt sein. Ist Lighting disabled, werden Objekte nicht mehr geshadet und erscheinen so zweidimensional. ShadeModel bestimmt, ob Flächen smooth oder flat geshadet werden sollen. Werden Flächen flat gerendert, heißt das das die gesamte Fläche die gleiche Farbe hat. Smooth hingegen erlaubt Farbverläufe auf Flächen, also genauere Shadings. Wer sich immer noch nichts drunter vorstellen kann, probiert's mit 'ner Standard-Kugel (16 Stacks, 16 Slices) einfach mal aus

Die ContextOptions sind Optionen für den OpenGL-rendering context.
Die Optionen sind:

• DoubleBuffer: DoubleBuffering wie bei der Tform
  
• RenderToWindows = Wird in der aktuellen (CVS-)Version ignoriert und ist irgendein überbleibsel aus alten Zeiten
  
• TwoSideLighting = ein Two-Side-Lighting Modell, nur wenn es True ist, werden beide Seiten von Flächen gelightet, sprich: die BackFace sieht man nur, wenn beide Seiten gelightet werden sollen.
  
• Stereo = Da ich weder eine Dual-Head-Karte habe, noch etwas von 3D-Stereorauschen weiß (ihr wisst schon, diese seltsam gemusterten Bilder die dreidimensional erscheinen), weiß ich nicht, wie ich es übersetzen soll. Entweder das eine, oder das andere, überprüfen kann ich es aber nicht (Wer eine Dual-Head-Karte hat, kann sich ja mal bei mir melden)
  
• DestinationAlpha = Erfordert einen Alpha-Kanal für die Ausgabe (welche Auswirkungen das genau hat, weiß ich nicht)
  
• NoColorBuffer = diese Funktion habe ich nie verstanden. Evtl kann Aya erklären, wieso man auf die Idee kommt, die Bitplanes für die Farben im Pixelformates des RenderingContextes alle auf 0 stellt

Die Geschichten um Fog sind für Nebel bestimmt. Entweder komme ich dazu später, oder ihr probiert es selbst aus, sonderlich kompliziert ist das nicht, passt nur nicht hier zum Thema.



So, haben wir also auch den SV abgeklappert. Fehlen nur noch die Kameras und die Lichtuellen.
Am seltensten wird wohl der CameraStyle verändert. Er bestimmt, wie die Kamera das Bild „sieht“. Die Optionen sind schnell erklärt:

• Perspective = Perspektivische Sicht, wie das menschliche Auge
  
• Orthogonal = orthogonale (non-blended) 2D-Perspektive. Da Entfernung keine Rolle mehr für Größenverhältnisse spielt, ist ein Zoom nicht mehr durch größere Distanz zum Objekt, sondern nur noch durch den SceneScale zu erreichen
  
• Ortho2D = Wie Orthogonal, nur eine Einheit entspricht einem Pixel (entspricht gluOrtho2D)
  Custom = Der Viewport kann im OnCustomPerspective-Event beliebig angepasst werden, auch dynamisch veränderbar und alles

DepthOfView gibt die FarClippingPlane an. Alle Objekte, die weiter von der Kamera entfernt sind als der angegebene Wert, werden nicht mehr gerendert (die NearPlane kann man nicht setzen, wird aber automatisch entsprechend der OpenGL-Dokumentation berechnet)

FocalLength gibt die „Brennweite“ der Kamera an, mit der man einen perspektivischen Zoom ervorrufen kann. Die NearPlane wird dabei entsprechend mitgeändert.
Wohingegen SceneScale einen reinen 2D-Zoom macht, das geenderte Bild also nur vergrößert oder verkleinert auf den RC zeichnet.
Target Object haben wir schon kennen gelernt. Eine andere (nicht objektgebundene) Methode die Ausrichtung der Kamera zu verändern, sind die Direction- und Up-Properties. Die Kamera schaut immer in Direction und Oben ist immer Up. So kann man auch ohne Objekte eine Kamera ausrichten (auch wenn der Grund sowas zu tun nicht ganz offensichtlich ist...).

Kommen wir zur Lichtquelle. Sie hat wie die Materials 3 Farben (Emissive fehlt). Diese werden mit den Farben der Objekte, die beleuchtet werden, verrechnet. Es wurde bereits angesprochen, daß das Specular nicht sofort klappen würde. Der Grund dafür ist, daß Ambient und Specular standardmäßig auf Black stehen. Schwarz beleuchtet ergibt natürlich keine Specular-Farbe irgendeinen Effekt, also muss man auch das Specular der Kamera verändern. Weiß ist dafür neutral, aber mit anderen Farben lässt sich auch die Itensität der Reflexionen bestimmen. Wer damit rumexperimentiert und nicht zufrieden ist, sollte auf jeden Fall die Slices und Stack der verwendeten Kugeln erhöhen!
Der LightStyle gibt die Form des Lichtkegels an. Spot ist ein... Spot eben – wirft Schatten, leuchtet in die Richtung von SpotDirection und hat einen gewissen Bereich (angegeben durch Cutoff, allerdings verhält es sich wie Omni, wenn Cutoff = 180° ist). Omni ist ein Licht in alle Richtungen, leuchtet also alles aus. Paralleles Licht scheint Parallel (also nicht radial) und die Richtung due durch Direction angegeben ist, schattiert die Flächen allerdings nicht so gut wie Imno- oder Spot-Licht, sondern verhält sich eher wie die Sonne.
Die ganzen Attenuation-Properties stehen für verschiedene Arten, wie das Licht auf seinem Weg durch die Szene abgeschwächt wird. Besonders weit leuchtendes Licht, sollte nur eine konstante Verminderung haben, weil dann die Itensität immer gleich bleibt, während bei lineare und quadratischer Abnahme die Itensätit natürlich mehr oder weniger abnimmt.
Eng verwand damit ist der SpotExponent, der angibt, wie stark die Itensität des Lichts vom Inneren des Spots zum Außenrand hin abnimmt (bei 180° Cutoff wird SpotExponent ignoriert).


So, das war's nun aber entgültig. Wenn ich nicht noch was vergessen habe (bitte hnweisen:!, dürften das alle Basics gewesen sein, die mit den Objekten, der Hierarchie oder der Darstellung zu tun haben.
Ihr solltet einfach mal ausprobieren, welche Einstellung welche Auswirkungen hat. Einige sieht man nur, wenn mehrere Objekte in der Szene sind, also ruhig das Ding zubauen. Viel Speicher und Rechenzeit brauchen die einfachen Objekte nicht, also selbst die TNT- oder Rage-Besitzer können ruhig zugreifen.
Wer Fragen zu irgendwelchen besonderen Objekten hat, kann sie natürlich jederzeit stellen.


Der nächste Teil wird dann endlich über Bewegung sein, denn was ist die tollste Szene, wenn alles stocksteif in der Ecke liegt?

wow, das nenn ich doch mal ein tutorial (oder kann man schon e-book sagen ?)
sehr umfangreich und informativ, hat mir sehr weitergeholfen

THX

Danke
Endlich mal Rückmeldung
Ist halt ein Umfangreiches Thema, vor allem weil GLScene wirklich alle Möglichkeiten von OpenGL ausnutzt und nicht die Hälfte weglässt und sagt "das braucht eh keiner". Da sind Erklärungen schonmal lang

Kannst du nochmal über 3D postionen was schreiben ?
damit habe ich irgenwie immer noch probleme. ich bekomme es nie hin das ich eine planen angezeit bekomme....

Ein Plane sieht man in den Standardeinstellungen des Objektes immer nur von vorne, also in die Richtung des "Direction"-Vektors. Du musst die Kamera also entsprechend positionieren.
Wenn das Plane bei (0;0;0) ist und die Kamera auf einer Z-Position < 0 (also im negativen Bereich) sieht man das Plane nicht. Die Kamera muss also einfch nur vor das Plane (und natürlich auch mit TargetObject auf das Plane ausgerichtet sein).

es geht nicht, ich habe ne plane hinzugefügt und so gelassen und dann die camera auf das plane gerichtet und fertig. dann habe ich in der camera die postion von z verändert aber es hat leider nicht funktioniert
ich habe auch die camera mit der anzeige komponente verknüpft....

habe es geschaft..... musste nur die pos von der plane ändern

Meinung und mich grundlegend verändert.--> Beiträge gelöscht

hülfe...
ichhabe mir grade das packet von glscene.org runtergeladen, und die glscene.dpk installiert. die neuen komponenten usw sind auch vorhanden.

so bei dem nachstellen des tutorials bringt er mir folgende fehlermeldungen.

file not found: geometry.dcu und GLWin32Viewer not found,

ich hab doch nur installiert und gar nix kaputt gemacht...kann mir einer adbei helfen??

gruss

masteryoda hat folgendes geschrieben:

file not found: geometry.dcu und GLWin32Viewer not found,

Hast du den Librarypath entsprechend angepasst, wie am Anfang des Tutorials beschrieben? Allerdings sollte er dann nicht nur die geometry nicht finden, sondern auch alle anderen Units. Und der Win32Viewer sollte auch nicht das einzige Objekt sein, daß er nicht findet. Aber wenn die Datei vorhanden ist (such mal in dem GLScene-Verzeichnis, das du angelegt hast, dort im Unterordner "source" nach der geometry.dcu), kann es nur an dem Librarypath liegen.
Ansonsten weise ich immer wieder gerne darauf hin, daß das Komplettpaket von GLScene.org mehr als veraltet ist und das aktuellere im CVS liegt (weitere Hinweise am Anfang des Tutorials).

also ich hab den path angegeben wie es im tut. steht, und nach den dateien gesucht aber leider gibts die wohl nicht


dummerweise hab ich nicht CVS benutzt, ich lad mir die grad mal.

achja muss ich dann das alte Release vorher deinstallieren, udn wenn ja wie macht man das? *g*

vielen dank:)

gruss