Hallo,

ich habe folgendes Problem:
Ich muss für die Schule eine Art Demo machen die die Irrlicht Engine mit der Physik Engine ODE verbindet.
Nun ist nicht die konkrete Realisierung das Problem sondern die Vorgaben die mein Lehrer mir dabei macht.

Angenommen ich möchte einen Ball(kann auch ein Haus etc. sein) in die Demo einbauen dann würde ich schreiben



Ich würde also einen Pointer auf den SceneManager und alles was ich brauche in die Klasse reinmachen und dann damit arbeiten. Außerdem würde die Klasse eventuell noch teile der Physikdaten(für ODE) wie den Radius etc beinhalten. So ähnlich wurde es auch in dem Spiel Boltzplatz gemacht das auf der Irr Homepage gefeatured wird.

Mein Lehrer möchte aber nun, dass ich zuerst mal von ISceneManager erbe um eigene Methoden wie addBall() oder addWasWeissIch() hinzuzufügen. Weiterhin hat er sich für komplexere Objekte vorgestellt das diese von IAnimatedMeshSceneNode oder ISceneNode erben und dann Methoden wie doSomethingCool(); bekommen.

Nun ist meine Frage was für die erste und was für die zweite Lösung spricht. Ich sehe irgendwie keinen Sinn in der Tatsache das man von ISceneManager respektive ISceneNode erben soll um obige funktion zu realisieren. Außerdem glaube ich nicht dass das beim Entwurf von Irrlicht so gedacht war das man von SceneManager erbt um solche Methoden wie oben hinzuzufügen.

Danke für eure Hilfe
seth0012

Vom SceneNode Eigenschaften wie setPosition() etc zu vererben kann imho für eine einfachere Integrierung durchaus von Vorteil sein. Und du kannst diesen SceneNode dann in das Rendersystem integrieren und dir so viel Arbeit wie möglich von der Engine übernehmen lassen (automatisches Updaten der Position in der von der Engine aufgerufenen Funktion etc?).

Ich würde trotzdem die erste Methode nehmen, imho ist sie in quasi allen Aspekten besser als die zweite.

_________________
Meine Gameengine

Aus meiner Sicht hat der Lehrer eindeutig Recht.

Dein Ball ist doch im Prinzip ein SceneNode. Von der Basisklasse werden (wie der Name schon sagt) die Basisfunktionen bereitgestellt, also Position setzen, ist das Objekt sichtbar, etc...
Die Ball-Klasse muss sich dank der Vererbung nur noch um die Ball-spezifischen Aspekte kümmern.

also ich würde logische objekte (wozu ja ein ball gehört) eher nicht von sceneNode erben lassen. ein sceneNode ist für die grafische darstellung, zu einem objekt gehört aber mehr. und was ist mit objekten die aus mehreren sceneNodes bestehen?
mMn sollte ein objekt wie ein ball (oder eben auch komplere objekte) einen sceneNode benutzen, selbst aber keiner sein.

So dachte ich mir das auch denn ein Haus etc. besteht ja eventuell auch aus mehreren SceneNodes. Würde ich jetzt von SceneNode erben dann müsste ich wie oben im Code wieder SceneNodes in die abgeleitete Klasse einbauen. Dadurch geht ja die Anwendbarkeit der Basisfunktionen die fado beschrieb im Grunde verloren. Weil wenn ich zum Beispiel die setPosition() Methode von SceneNode erbe kann ich sie trotzdem nicht weiter verwenden da ich ja im Falle eines komplexeren Objektes von mehreren SceneNodes die Position verändern müsste. Ich lege meinem Lehrer heute mal die Argumente vor mal abwarten was er sagt.

Wenn aber jemand das "Killer Argument" für die eine oder die andere Methode hat wäre ich natürlich offen für Anregungen.

im grunde ist der gedanke nicht schlecht, aber: man kann einfach die anderen sceneNodes aus der das objekt besteht als kindknoten realisieren, die sowieso nur ihre position relativ zum elternknoten speichern, also automatisch mitverschoben werden wenn das objekt verschoben wird.. das ist ja der sinn des baums.

_________________
yo. life's so bloody short.
Ihr dachtet Schulfernsehn sei die ultimative Folter? Falsch: Fahrstuhlmusik, extra leise.

NinthBit hat recht! Generell wuerde ich die Render-Funktionalitaet von deinem Object 'trennen' - ein schoenes Beispiel (fuer deinen Lehrer als Argument) waere, dass Ogre3D (welches ja als Musterbeispiel einer OOP gilt) das selbst so von Haus aus macht... - dort hat man Entities (welche die MeshDaten enthalten) und SceneNodes von einander separat verwaltet... - in unserem Projekt werden die jeweiligen Game-Objects auch separat gehandelt, die wiederum (Ogre3D-)Entities enthalten und diese wiederum mit den SceneNodes verknuepft werden... - das ein Object 'zur angebl. Vereinfachung' von einer SceneNode die Funktionalitaet erbt, ist (verzeiht mir bitte den harten Ausdruck) totaler Schwachsinn!!! Ich code jetzt seit ueber 20 Jahren und wuerde niemals so an die Sache rangehen... - nicht boes' gemeint, sondern nur ein Ratschlag!