spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Da ich im Moment nicht Programmieren kann, beschaeftige ich mich halt mit dem Konzept meiner Engine. Nun frag ich mich grad wie ich die Render Engine am besten aufbauen soll? Ich mein damit nur die Render Unit und nicht das gesamte Grafik Interface.

Meine erste Idee war das ich die Render Engine in einen eigenen Thread auslagere, damit mit sie ungestoert ihre Arbeit verrichten kann. Der Ablauf soll dann etwa so aussehen.
1) Objekte erzeugen und zum Rendern freigeben.
2) Die Render Engine rendert dann einfache jedes Objekt das in der Liste steht.
3) Die Objekte werden veraendert. Z.B. weil sie Animiert werden.
Wobei Schritt 2 Paralell zu 1 und 3 lauft. Nun stellt sich aber das Problem der Transparentz. Die kann ich ja erst zum Schluss rendern. Das Objekt koennte dann aber schon wieder veraendert worden sein und wenn ich die Objekte Sperre bleibt das Programm wieder so lange haengen bis das jeweilige Objekt fertig gezeichnet wurde.

Wie wuerdet ihr das denn so machen? Was sein soll ist, das es eine Renderliste gibt in der alle Objekte enthalten sind die gerendert werden sollen. Die Liste wird dann auch nur einmal erstellt.

Wollte mich nicht Spezialisieren. Gar nicht so einfach eine Render Engine aufzubauen. Eine Render Liste ist natuerlich vorhanden, und da der Renderer ja nicht wissen kann wie man alles Rendern soll, bekommt natuerlich jedes Render Able Object eine Rendermethode die dann das Rendern uebernimmt. Jedoch entscheidet die Render Engine fuer welches Objekt welches Render Methode aufgerufen wird.

Ich dachte auch an Prioritaeten, das man festlegen kann welches Objekt als erstes und welches als letzt gerendert werden soll.

Es ist auch die Frage ob ich die Render Engine in einen Thread auslagern soll. So das sie immer Arbeitet. Das heatte dann z.B. den Vorteil das man bestimmen kann wieviele Frames pro Sekunde moeglich sind. Aber wie Syncronisiert man dann das ganze?

Hmm...noch wer Ideen oder anregungen?

Also hab mal wieder ein kleines Problem. Ich hab mir ein nettes kleines System ausgedacht in bezug auf Images und Texturen. Die Render Unit sollte eigentlich nur Texturen Rendern koennen und einzelne Texturen sollte es auch nicht geben, sondern nur Materialien.

Also, ich habe Images eingefuegt damit ich eine Basis bekommen fuer Konvertierungen (Farbe, Groesse, etc.) Ein Image wird aber intern als Textur gehandhabt (Idee war der 2D Render Support).

Dann sollte es Materialien geben. Die sind von den Images abgeleitet, damit ich sie ebenfalls Konvertieren kann. Ein Material ist eine Textur mit den Reflexionsdaten fuer das Licht.

So...nun ist mir allerdings etwas aufgefallen.
1) Ein Image darf keine Textur sein, weil ein Image ja nur ein Bild ist und ein Bild nicht unbedingt die Dimensionen einer Textur haben muss. Der Sinn eines Images ist also nicht erfuellt.

2) Wenn ich nur Materialien haben ist das ersten unsennig (was soll z.B. eine Detail-Map mit Reflexionsdaten? ) und zweitens wie verbinde ich bei Multitexturing die Lichtinformationen?

Also hab ich noch das Textur Interface dazwischen geschoben. Nun sind Images das was sie sein sollen. Eine Textur ist dann ebenfalls das was sie sein sollen. Nun habe ich ja noch Materialien. Mein Problem ist, oder eher stelle ich mir die Frage, wie ich jetzt das Material Definieren soll.
Besteht ein Material nur aus einer Textur und dessen Reflexionsdaten oder koennen es dann auch mehrere Texturen sein? Wenn ein Material auch mehrere Texturen haben darf ist das Effekt Interface irgendwie ueberfluessig.

Wie Definiert ihr denn Eure Materialien. Habt ihr ueberhaupt ein solches Interface?

Ui...hätte nicht erwartet auf meine Postings noch Antworten zu bekommen

Also mit dem auslagern der Renderunit in einen Thread hab ich erst einmal fallen gelassen. Da es doch ein sehr hoher Syncronisierungsaufwand ist.

Das Rendern über Prioritäten war halt mal eine Idee. Die ich jedoch wieder verworfen habe. Die Renderliste wird bei der Initialisierung aufgebaut und anschliessend Sortiert. Die einzige Sortierung die zur Laufzeit geschieht ist die, die einem die Transparenten Teile der Modelle sortiert.

Das Texturinterface hab ich ebenfalls wieder herrausgenommen. Benutze jetzt nur ein Image Interface und ein Material Interface das vom Image Interface abgeleitet ist. Das Problem der Dimensionen ist eben genau das was ich mit dem Image ebenfalls Lösen wollte. Das ganze geht dann etwa so:
1) Laden einer Bitmap in ein Image Interface
2) Erzeugen eines Material Interfaces
3) Imagedaten in das Materialinerface kopieren.
Bei Schritt drei werden die Daten so Konvertiert das sie in das Materialinterface hineinpassen (Größe & Farbformat) Natürlich gibt es noch ein eigenes Dateiformat für Materialien Da ein Material neben den Lichtinformationen auch Transparentsinformationen enthält. Was die Verknüpfung der Lichtinformationen angeht, da hab ich mir ein paar States gebastelt, die man dann im Effekt setzen kann.
Aber das Image Interface ist auch dafür da um Bilder z.B. zu Filtern. Was man z.B. für die erzeugung von MipMap's gut gebrauchen kann.

Ja es ist sehr schwer alles möglichst Allgemein zu halten. Daher ist die Render Unit auch nicht darauf ausgelegt z.B. BSP Bäume zu Rendern. Die Engine kann verschiedene Arten von Bäumen Rendern. Wie ich das alles jedoch bewerkstellige weis ich noch nicht so genau. Hab bis jetzt nur ein paar Ideen, wie es gehen könnte. Hatte in letzter Zeit nicht viel Zeit mich darum zu kümmern.
Der Typ (Indoor, Outdoor, Nodoor) eines Level's soll erst durch die Implementierung des Level Interfaces geschehen.

Hui...na dann packen wir mal wieder einen alten Thread aus

Natürlich wieder einmal die Render Unit. Meine Engine nimmt so langsam ein wenig gestallt an. Vor allem was das Grundkonzept angeht. Da hab ich es bis jetzt sehr gut hinbekommen das sie zu 100% flexibel ist. Einfach alles, vom kleinen Log Interface bis zum ganzen Graphic Interface, ist erweiterbar und/oder ersetzbar. Es ist sogar möglich Debug Modus und Release Modus inerhalb eines PlugIn von Interface zu Interface zu wechseln.

Jedoch macht mir meine Render Unit da einen dicken Strich durch die Rechnung. Bis jetzt sieht es überall so aus das ich nur mit den Interfaces Arbeite und es mich nicht Interessiert wie es Implementiert wurde. Nur die Render Unit macht da nicht mit.
Also muss Plan B her. Da sieht es so aus:
Kurz zum Aufbau. Ich habe Renderlisten in denen alle Objekte eingelagert werden. Jedes Objekt das gerendert werden kann ist von einem speziellen Interface abgeleitet. Die Render Unit soll nur mit diesem Interface Arbeiten.

Nun zu Plan B. Da heißt es, die Render Unit wird in zwei Teile aufgeteilt. Einmal Teil A. Der kümmert sich um die Verwaltung der Renderlisten. Einlagern von Objekten, Sortierung, etc. Dann gibbet Teil B. Dieser Teil ist ein Interface IRenderUnit. Dieses Interface wird dann Speziell für ein Render Able Inerface Implementiert. Z.B. für ein Mesh Objekt.
Das schöne daran, es ist mögliche selbst unbekannte Interfaces zu Rendern. Man brauch nur das IRenderUnit Interface neu Implementieren.

So, aber ich denke da naht schon das Gewitter. So schön es klingen mag habe ich die Befürchtung das ich damit den reinsten Overkill Programmiere. Da man dann sehr viele Funktionsaufrufe mit Virtuellen Methden hat. Und die Render Unit ist ja nun ein sensibler Bereich.


Und damit steh ich vor dem Dilema keinen Plan C zu haben :crying: Im Moment steh ich da was auf der Leitung. Hier mal was ich will. Vieleicht hat ja jemand eine zündende Idee. Alle Objkte die gerendert werden können, werden in Render Listen einsortiert. Dort werden sie dann nach Materialien und Effekten sortiert. Die Aufgabe der Render Unit besteht in der Verwaltung der Render Listen und dem rendern der Objekte. Dabei sagt die RU jedem Objekt was es zu tun hat. Also z.B. Setzte LOD Level 3 oder Aktiviere RS für Pass 0.
Erreichen will ich damit das ich so wenig wie möglich Redundante Operationen habe. Es soll aber auch möglich sein die Render Unit zu erweitern. Flexiblität ist eines meiner Grungesetzte für die Engine.

Na wenn du meinst. Naja es dürfte nicht al zu viel Aufwand sein das ganze wieder umzubauen. Nagut dann werd ich mal bei Plan B weiter machen Das Design ist nämlich sehr Praktisch.