Designfrage Camera Klasse



  • Hi,

    hab mal ne kleine Designfrage zu meiner Camera Klasse für eine 3D-Anwendung. Ich habe 2 Typen von Kameras: Eine frei bewegliche und eine, die immer auf ein Ziel fixiert ist. Eigentlich wollte ich es mit einer Klasse implementieren, der man im Ctor per enum Wert die Art der Kamera übergibt. In den Methoden wird dann wo nötig mit nem if() auf den jeweiligen Typ eingegangne. Also in etwa so:
    Camera freeCam(0, 2, 3, FREE_CAM);
    oder
    Camera targetCam(0, 0, 1, TARGET_CAM);

    und z.B.:
    void Camera::StrafeLeft(float translation) {
    if(cameraType == FREE_CAM)
    // verschiebe nach links
    else
    // mache krasse Kreisbewegung nach links und bleibe aufs Ziel ausgerichtet
    }

    Meine Frage: Ist das gut so oder sind die paar if() in einigen Methoden ein Indiz dafür, dass ich eher ableiten sollte? Aber ich wüsste dann garnicht genau, welche Klasse von welcher erben sollte.
    Hm, wie würdet ihr das designen? 😕



  • ich würde es so machen, dass eine camera ein T*target hat. Wenn target != 0 ist, dann wird die camera nach erfolgter bewegung wieder neu auf target ausgerichtet:

    void Camera::StrafeLeft(float translation) { 
        // verschiebe nach links 
        angleToTarget();
    }
    
    void camera::angleToTarget() {
        if (target)
            // ausrichten
    }
    


  • Also zwei verschiedene Klassen würde ich an der Stelle nicht verwenden, da du, falls du den Kameratyp wechseln möchtest, immer deine alte Kamera zerstören und eine neue anlegen müsstest...
    Ich aber die Kameratypen innerhalb der Klasse nicht unterscheiden, sondern nur eine Kamera implementieren, die entweder ein Ziel haben kann, oder nicht. Je nach dem würde ich dann den Blickvektor der Kamera festlegen und mich bei allen Bewegungsoperationen auf diesen beziehen.

    Grüße,

    Martin

    edit: Ja, so wie pixelshooter hatte ich mir das auch ungefähr gedacht



  • Hm.
    Ich würde das über einen Controller regeln... also über eine externe Klasse.



  • Hmm ... kommt drauf an ... wenn du noch nach außen hin flexibel für Erweiterungen (neue Kameras) sein willst, empfiehlt es sich, einfach eine Basisklasse ICamera anzulegen. Wo du die Kamera dann brauchst, legst du einen einen Pointer auf diesen Basistypen an. Für jede spezielle Kamera einfach eine neue Klasse von ICamera ableiten. (Polymorphie) ...



  • die meisten 3D Design programme machen es so:
    Es gibt Camera:Objekt. Ein Objekt hat ein Achsensystem, kann verschoben werden etc. eine camera kann halt außerdem filmen.

    Dann gibts ausrichtugstags. Die könnte man so realisieren, dass, sobald sich etwas an der szenerie ändert (müsste die szene von den objekten gemeldet bekommen), ruft die szene die tags auf (szene muss alle tags kennen), die ihnen zugeordneten objekte zu verändern.
    Zum beispiel kann ein align tag dann nach einer manipulation wieder die manipulatoren benutzen, um ein objekt wieder auszurichten.



  • Eventuell das State Pattern anwenden? Nur so eine Idee, ich hab jetzt auch keine Lust das auszuführen.



  • Hmm ganz normalerweise ist eine Kamera auch nur ein Node in einem SceneManager ^^



  • (D)Evil schrieb:

    Hmm ganz normalerweise ist eine Kamera auch nur ein Node in einem SceneManager ^^

    Was hat das mit der Frage zu tun?

    State Pattern.. wtf?! Nene, ich mach das jetzt ganz simpel und unterscheide mit einem enum die 2 Kameratypen^^



  • Hab mir gerade mal das State Pattern auf Wiki angeschaut (http://en.wikipedia.org/wiki/State_pattern) und hätte dazu jetzt kurze einige Fragen:

    Die Klasse DrawingController hat Methoden, die den konkreten Zustand setzen (selectPenTool() etc.). Aber das ist doch schlecht, da beim Schreiben der Klasse Controller bereits alle Subklassen von AbstractTool bekannt sein müssen.
    Umgehen kann ich das ja nur, wenn ich DrawingController eine Methode wie setAbstractTool(AbstractTool
    tool); gebe, oder?

    Wieso benutzt DrawingController einen std::auto_ptr? Da kann ich ja auch einfach einen normalen Pointer benutzen und bei jedem setAbstractTool ein delete machen, oder?


Anmelden zum Antworten