[Engine Design]

KXII

warum willst du dass denn in 2 verschiedene klassen packen? nur ein objekt selber kann wissen, wie es sich selber zeichnet. das sollte man nicht anderen klassen überlassen. meine klasse CObject3D ist die basisklasse für alle 3dobjekte. und nur sie allein soll in der methode "Draw" alle notwendigen dinge tun, damit sie (von directx) gezeichnet wird.

ja, ich rendere alle meine objekte direkt in der mainloop oder in einer in ihr aufgerufenen unterfunktion (was ja das selbe ist). objekte werden "innerhalb" von mainloop gerendert, was auch wichtig ist, da ausserhalb von mainloop das directx D3DDevice->Begin() und D3DDevice->End() steht.

in der praxis läuft das alles natürlich viel komplexer ab. man schreibt sich neue klassen die objekte (CObject3D) behinhalten. diese klassen haben dann ihre eigenen draw methoden. die aber nichts anderes tun als die draw methoden der einzelobjekte aufzurufen.

wenn du willst kannst du die klasse CRender so schreiben, dass sie all deine objekte in einem dynamischen array verwaltet und dann in einer eigenen draw-methode folgendes macht:

CRender
{
public:
  void CreateObject(const char *File); //oder sowas ähnliches

  void Draw(void);

private:
  CObject3D *m_Object;
  unsigned short m_ObjectNumber;
};

void CRender::Draw(void)
{
  unsigned short I;

  for (I=0;I<m_ObjectNumber;I++)
  {
    // hier noch eventuell sachen wie setmatrix oder setstate(xyz)
    m_Object[I].Draw()
   //hier auch noch andere sachen falls nötig  
  }
}

wenn du dann in der mainloop m_MyRender.Draw() aufrufst, dann werden alle objekte in mainloop gerendert (indirekt natürlich).

oder was meinst du damit, dass nicht alle objekte in mainloop gerendert werden?

prinzipiell würde ich die directx-funktionen die nötig sind, damit eine klasse was macht, nur in der klasse selber aufrufen und nicht in andere klassen packen. das macht alles nur unübersichtlicher und wiederspricht auch ein bischen der objektorientierten programmierweise.

zur projektionsmatrix:

D3DXMatrixPerspectiveLH(&ProjectionMatrix,0.2f/m_Zoom,0.2f/m_Zoom*m_AspectRatio,0.1f,10000000.0f);

in diesem beispiel ändert sich nichts. m_AspectRatio sowieso nicht. aber in einem spiel oder einer komplexeren andwendung als dieses beispiel, änder sich der zoom fast ständig, so das sich der einfachheit halber alles in unpdate gepackt habe. sonst müsste ich ja ein UpdateZoom() und ein UpdatePosition() jeweils einzeln aufrufen.

ich glaube auch nicht. das die projektionsmatrix viel performance schluckt, wenn sie ständig neu gesetzt wird. da sich ja nur eine matrix ändert. auch wenn directx dann noch ein paar interne änderungen vornimmt. sollte das nicht viel zeit kosten.

rapso

in meiner engine hab ich einen cullingtree

z.B. CSphereTree m_Tree;

wenn ich da etwas raus rendern möchte, holl ich mir eine entsprechende camera

ICamera* pCam=m_Scene.Camera("Camera01");

die camera hollt sich dann alle objekte aus dem tree die zu sehen sind

pCam->PickVisible(&m_Tree);

dann kann ich die sachen zeichnen lassen mit pCam->RenderList();

dadurch kann ich z.B. für multipass nur einmal cullen, für nicht bewegte scenen nur einmal cullen und ich kann mehrere cameras haben die sich auch rekursiv aufrufen könnten z.B. um auf schadowmaps zuzugreifen.

Renderlist geht dann die liste durch und sagt jedem objekt es soll sich rendern, dieses setzt dann das richtige renderscript und ruft vom mesh die render funktion auf.

natürlich läuft das in der engine

im mainloop mach ich an sich nur

pblablaengine->Render(MainCam);

MainCam ist die normale camera und Render ist die funktion in der engine.

rapso->greets();

rüdiger

also ich hab eigentlich noch keine richtige 3D Engine geschrieben, nur mal was kleines für ein kleines 3D CAD Programm. Dabei hatte ich folgende Klassen

color_type----
 |      |     |
rgb   rgba  texture

coord

light

material

primitive----------------------------
 |        |      |      |   |       |
triangle quad  point  line polygon text

modell

modell lädt die CAD Dateien und erstellt die entsprechenden primitive, diese benutzen coord zum erzeugen der Vertexes

btw.
sollte man kein C als Präfix für Klassen benutzen!

wieso sollte man kein prefix für klassen benutzen?

rapso

klingt fast wie ne linux lehre obwohl es nur geschmackssache ist.

ich hab ein I prefix für interfaces C für normale klassen und S für structs... und das ist recht angenehm damit zu arbeiten. bisher hatte ich keinen grund auf sowas zu verzichten bzw. deswegen nachteile zu haben, ist ja nur etwas für die durschaulichkeit und übersichtlichkeit von code....

rapso->greets();

Original erstellt von meister der mnemonics:
wieso sollte man kein prefix für klassen benutzen?

Das ist in einem Thread in "Rund um die Programmierung" seitenlang durchgekaut worden, such mal danach!

Übersichtlicher ist es nicht; eher schwerer zu lesen.

Christoph

C ist sowieso für die MFC gedacht.

TGGC

Wichtig auch immer die C's am Anfang der Klassennamen, sonst ist die Engine Mist...

Ich empfehle X.

ich hab ein I prefix für interfaces C für normale klassen und S für structs... und das ist recht angenehm damit zu arbeiten. bisher hatte ich keinen grund auf sowas zu verzichten bzw. deswegen nachteile zu haben, ist ja nur etwas für die durschaulichkeit und übersichtlichkeit von code....

Gute Idee

rapso

Original erstellt von TGGC:
Wichtig auch immer die C's am Anfang der Klassennamen, sonst ist die Engine Mist...

endlich mal gleicher meinung

:D:D:D

rapso->greets();

rüdiger

also zwischen structs und classes bei C++ zu unterscheiden ist eigentlich ziemlich sinnlos IMHO und dann auch noch C als Namens Prefix zu nehmen um möglichst Konflikte mit der MFC hervorzurufen ist doppelt Sinnlos.

(wobei meine Erfahrung mit typischen Spiele/Grafik/Spiele-Tutorial Code eh nicht die besten sind )

aber die Diskussion ist eh Sinnlos und sorgt nur für einen Flamewar!

rapso

du hast das wörten "weil" vergessen und den satz der dahinter folgt und eine objektive erklärung gibt, die man nachfolziehen kann. sonst ist das irgendwie nur ne meinung.

würde ich nicht I,S,C und N vor schreiben, dann hätte ich nur konflickte, schliesslich heißen interfaces genauso wie die dazugehörigen klassen (bis aufs prefix)... und mit MFC hat man sowieso nur ärgerlichkeiten (meiner erfahrung nach).

rapso->greets();

RenéG

Apropos Namenskonflikte, ist das überhaupt ein Thema?

Ich weiss nciht, wieviele Abhandlungen von list<>, vector<>, map<> u.s.w. ich schon gesehen habe, alle den gleichen Namen. Aber aufgrund von Namespaces doch kein Problem!

rapso

ist auch meine meinung, aber die MFC hat wohl keinen namespace soweit ich weiß...

rapso->greets();