was sollte sie können und wozu ist sie gut?

während ich auf eine lösung des restless problems warte möchte ich meine Kammere Klasse entwickeln die ich ja auch mal benötige um mich gut im raum unzusehen, jetzt frag ich mich aber was diese können sollte und warum ich umbedingt eine brauche, ich kann die kammerposition ja auch in nem record speichern und das geht auch.

also irgendwie steh ich sozusagen gerade zwischen den punkten, brauch ich und brauch ich nicht, vieleicht kann ja einer von euch mir paar sachen sagen wozu eine kammera klasse wirklich gut ist.

lg

Guck mal hier : http://www.delphigl.com/forum/viewtopic.php?f=13&t=9811

Nach meiner Meinung kommst Du um eine Berechnung der Matrizen von OGL nicht herum. Es ist einfacher im Code.

Gruß Jens

Möchtest du objektorientiert oder imperativ programmieren? Das sind einfach zwei verschiedene Konzepte. Die meisten neueren Programmierssprachen sind heute objektorientiert (z.B. Delphi, C++, Java, PHP, Python, Perl ...)

Die Grundidee bei der Objektorientierung laut Wikipedia:

Diese Datenkapselung macht die Programme besser lesbar/wartbar. Die Schnittstelle nach außen wird möglichst klein gehalten, andere Programmteile können die Daten nur über die Schnittstelle verändert werden. Die Schnittstelle ist quasi eine Brücke die sicherstellt dass der Objektzustand immer valide ist.

Des weiteren gibt es bei Objekten/Klassen die Möglichkeit der Vererbung. Angenommen du möchtest verschiedene Kameratypen (etwa Ego-Shooter und Third-Person) könntest du eine Basisklasse "BaseCamera" schreiben die die Gemeinsamkeiten enthält. Gemeinsamkeiten wären etwa das extrahieren der 6 Frustum-Ebenen aus der Kamera-Matrix. Davon würdest du dann die Klassen "EgoCamera" und "ThirdPersonCamera" ableiten, wo dann die Unterschiede implementiert werden.

_________________
Yeah!

also allein das argument der objektorientiertheit find ich bisschen schwach, aber unterdessen hab ich mir überlegt das ich eventuell noch paar sachen brächte wie an ein objekt binden oder freigenen, mehrere kammeras und all so zeug,
whabt ihr selbe kammera klassen? was können die so?

• Kamera Frustum (= 6 Ebenen) berechnen, Sichtbarkeitstest für eine BoundingBox durchführen. Eine andere Klasse nutzt diese Funktion um eine Liste der sichtbaren Objekte in der Szene zu generieren.
• set()-Methode setzt die Modelview und Projektions Matrix für OpenGL
• clear()-Methode ruft glClear auf. In einer Unterklasse wird das dann überschrieben um z.B. einen Hintergrund (z.B. Skybox) zu zeichnen.
• update()-Methode kümmert sich um die Auswertung der Mausbewegung, Tastendrücke usw. (Info wird von einer anderen Klasse zur Verfügung gestellt). Die Kamerabewegung passiert aber hier. Wird natürlich in der Unterklasse überschrieben.
• in meiner Anwendung kann es mehrere Ansichten gleichzeitig geben. Es gibt daher eine Funktion um Kameras mit einander zu synchronisieren
• Unterklassen für verschiedene Kameratypen: Ego-Kamera, Trackball-Kamera, Aerial-Kamera (wie Google Maps), Selection-Kamera. Letztere wird beim Color-Picking benutzt, sie berechnet aus einer anderen Kamera und der Cursor-Position eine spezielle Kameramatrix so das nur ein kleiner Bereich von wenigen Pixeln gerendert werden muss.

Wird wahrscheinlich daran, dass du das objektorientierte Konzept noch nicht verstanden hast. Hat bei mir damals auch was länger gedauert Insbesondere die Nutzung von Vererbung und Polymorphie vereinfacht vieles! Du kannst einfach alle Objekte gleich behandeln ohne überall riesige Fallunterscheidungen zu haben. Auto-Vergleiche sind ja immer gut:
Du kannst ein Auto fahren in dem du einfach die Methode auto.fahren() aufrufst. Dabei ist es egal ob es sich bei "auto" um einen Ferrari oder einen Fiat Punto handelt. Ohne die Polymorphie bräuchtest du quasi für jedes Auto einen eigenen Führerschein.

_________________
Yeah!

Im prinzip kann meine Camera klasse nur "sehr wenig", allerdings liegt das am gesamt aufbau..

Sie hat nur ein paar sehr wichtige funktionen, zum einen "render()" bzw "renderRegion(...)" sind die funktionen die ich aufrufe um eben die Scene aus sicht dieser Kamera zu rendern.

"addPostRenderEffect()" und co sind für PostRender Effekte wie glow etc zuständig - das ganze gibt es sowohl als "Global Effect" als auch als "Camera Effect".. also ich kann einen Effekt einer speziellen Kamera zuweisen oder eben allen immer.

Dann noch ein paar funktionen á la getModelviewMatrix(), getProjectionMatrix(), getResolution() etc.

getRay() liefert mir an screenPosition X/Y einen Ray den ich für Raytracing etc nutzen kann.


Die bewegung der Kamera läuft bei mir über Transform-Nodes. Die Kamera stammt vom Typ CIObject ab (wie z.B. auch CIPolyObject, CINurbsObject etc). Jedes CIObject kann eine Transform Node haben welche die Transformationen übernimmt.

Daher habe ich nur meine eine CICamera und zusätzlich dazu dann CIEulerTransform (Steuerung via Translation, Rotation und Scaling), CIQuaternionTransform (Steuerung via Quaternion), CIPathTransform (Bewegung an einem Pfad entlang), CIMoveableTransform (Bewegung wie im Egoshooter inkl. collision detection), CIMayaTransform (Steuerung wie in Maya), CICarTransform (Steuerung für Autos) und noch einige andere..

Das ganze kommt bei mir daher das ich beruflich viel mit Maya und 3D Programmen zu tun habe und mich daher am aufbau eher an diesen orientiert habe als an einer Game Engine. Mag zwar teilweise etwas merkwürdig sein, macht aber alles viel sinn in dem moment wo man nicht nur rein spiele damit programmieren möchte oder mehr als OpenGL unterstützen will. (Ich kann z.B. jederzeit in meiner Engine einen knopf drücken und in dem moment wird das aktuelle frame mit einem Raytrace-Renderer in HighQuality gerendert).

Das Transform Konzept hat auch den riesen vorteil das wenn ich eine neue bewegungsart einbauen möchte dies nicht für jede Objektart (Camera, Mesh etc) machen muß, sondern lediglich eine Transform erstelle und diese dann den Objekten zuweise.

Aber, eine kleine wichtige sache die beim Kamera-Klassen-design bedacht werden sollte - falls du sowas mal vorhast - sind Stereoskopische Kameras. Das ist in meinem Falls so gelöst das die CIStereoCamera intern 2 CICamera Objekte hat welche via EyeDistance, EyeConvergence etc steuerbar sind. In der render() funktion wird einfach die render-funktion der beiden kameras nacheinander aufgerufen und in einen Framebuffer gerendert, welcher dannach via PostEffekt composed wird.

Alle funktionen wie getModelviewMatrix() der StereoCamera liefern dann immer den wert der aktuell rendernden Kamera zurück.

Aya~

also erstmal entschuldigung wür die massiven vertipper in meinem letzten beitrag das sieht nicht gut aus^^

aber eure kammera klassen scheinen ja ne menge zu können, naja dann weiß ich ja was ich mach wärend ich versuche die objekte zum laufen zu bekommen,

danke euch für eure anregungen
lg

Ich habe anders als Coolcat und Aya meine Kameraklasse mehr als Transformation gebaut und weniger als Renderer.

So sieht meine Basisklasse aus (das sagt vielleicht etwas mehr, als ich beschreiben könnte)
Davon leite ich eine Perspektivische Kamera ab, die entsprechend die berechnung der Projektionsmatrix anpasst. Verschiebungen werden in der ModelView Matrix untergebracht. Die Update-Methode wird in noch einer Ableitung benutzt, wo ich sanfte Kamerabewegungen mit Beschleunigung/Dämpfung eingebaut habe, die dann in der Update-Methode angewandt wird.
Das Rendern geschieht nicht in der Kamera, die wird nur nach ihren Matrizen gefragt.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Bei mir ist das eigentlich auch so. Man kann aber eben prüfen ob eine gegebene BoundingBox aus Sicht der Kamera sichtbar ist. Die Kamera weiß damit aber nichts von der Szene und kann sie auch nicht rendern.

Hier mal meine Klassenhierarchie:

• Frustum
  
  • Camera (abstrake Klasse)
    
    • WidgetCamera (abstrake Klasse, Kameras mit User-Input von einem QGLWidget)
      
      • EgoCamera
      • TrackballCamera
      • AerialCamera
    • SelectionCamera

_________________
Yeah!