DGL
https://delphigl.com/forum/

Demonstrationsprojekt
https://delphigl.com/forum/viewtopic.php?f=21&t=7275
Seite 6 von 6

Autor:  Lord Horazont [ Fr Feb 29, 2008 18:13 ]
Betreff des Beitrags: 

TAK2004 hat geschrieben:
Eine weitere Lösung, vieleicht auch die bessere wäre eine Kamerapfad im Raum(vom plugin festgelegt) und laufen im Gang(eine fertige Physiklösung oder eine eigene, die beim raum betreten abgeschalten wird). Aussehen könnte dann sowas wie folgt. Kamera startet und fliegt zu einem bestimmten Punkt und wartet, der User kann nun in alle Richtungen gucken und auch interagieren(wenn was verfügbar ist) und dann fährt die Kamera zum nächsten Punkt.


Also ich bin gegen diese Lösung. Während der Entwicklung eines Plugins dürfte es ziehmlich nervig sein, wenn man diverse Parameter ändert und dabei ganz bestimmte stellen betrachten will, die sich aber immer wieder ändern. Dafür dann immer durch die einzelnen Kamerapfadpunkte zu switchen halte ich für sehr ungünstig. Außerdem wird der Benutzer dadurch in einer in meinen Augen sehr "fiesen" Art eingeschränkt. Man könnte das allerdings optional machen, sozusagen der "Museumsführungsmodus".

Gruß Lord Horazont

Autor:  The-Winner [ Fr Feb 29, 2008 19:40 ]
Betreff des Beitrags: 

Ich würde eine fliegende Kamera ohne physik nehmen. Allerdings frei steuerbar und nicht an einen pfad gebunden.
Wenn der Gang nicht allzukompliziert ist, sollte man Wände ohne größeren Aufwand undurchfliegbar machen können, und dies als API den räumen zur verfügung stellen können.

Autor:  i0n0s [ Fr Feb 29, 2008 19:48 ]
Betreff des Beitrags: 

Wieso muss es eigentlich ein fester Raum sein? Wenn wir einfach eine Tür machen kann das Plugin frei entscheiden was es dahinter macht und wir haben auch keine Probleme mit Überschneidungen irgendeiner Art da entweder ein Plugin oder das Framework aktiv ist. Und Sachen wie Modells/Texturen etc. sollten komplett frei wählbar für Plugins sein, da es mit keinerlei Einschränkung für andere Plugins verbunden ist. Einzig bei Sound müsste man schauen. Ich weiss nicht ob man die einzelnen Sachen beliebig oft initialiesieren und deinitialiseren kann. Wenn doch wäre auch dies kein Problem.

Autor:  Lord Horazont [ Fr Feb 29, 2008 20:54 ]
Betreff des Beitrags: 

Hmm... Ob man die Beschränkung "Raum-mit-Fenster" entfernen sollte weiss ich nicht. Allerdings kann man mit einer Außenlandschaft natürlich auch eine Menge Dinge anstellen. So gesehen bedeutet diese Beschränkung auf eine gewisse Anzahl an Effekten zu verzichten - oder jemand Implementiert ein schönes Gewitter im Raum :wink:.

Gruß Lord Horazont

Autor:  BenBE [ Fr Feb 29, 2008 21:50 ]
Betreff des Beitrags: 

Think outside the Hypercube ;-)

Wer sagt, dass ein Raum eine Innendarstellung sein muss?

Sehen wir's doch mal so: Ich gehe durch eine Tür, die effektiv die Sicht zwischen den Räumen verdeckt. Somit ist zu jedem Zeitpunkt entweder genau ein Plugin am Rendern, oder der Flur wird dargestellt.

Wenn nun ein Raum dargestellt wird, wer verbietet einem, eine Ansicht ähnlich der Halloween-Folge der Simpsons zu machen, wo Mitten im "Raum" eine Tür ist, durch die man wieder zurück in den Gang kommt. Im Normalfall ist diese Tür nämlich einfach nur an einer der Wände im Raum, in Ausnahme-Fällen kann aber auch ein Plugin eben eine beliebige Welt bauen. Bietet man hierfür eine kleine API an, die einem einen vordefinierten Raum zeichnet, kann jeder selber entscheiden, ob er in einem Raum seinen Effekt präsentieren will, oder ob er diesen "im Unendlichen" platzieren will.

Und für die Übergänge zwischen Flur zu einem solchen Raum: Der Raum zeichnet sich einfach zuerst und teilt dann der API mit, dass er fertig ist. Solange der User noch nicht vollständig im Raum steht, wird nun zusätzlich noch ein Türrahmen gemalt, fertig! Beim Verlassen des Raumes genauso. Die einzige Festlegung für solch einen Effekt wäre in diesem Fall, die größe der Tür ;-)

Autor:  Nils [ Fr Feb 29, 2008 22:02 ]
Betreff des Beitrags: 

So kann man das durchaus problemlos realisieren. Denn dann kann wirklich jeder machen was er will und er bestimmt die Fenster und das, was hinter den Fenster zu sehen ist, selbst.

Autor:  TAK2004 [ Sa Mär 01, 2008 15:20 ]
Betreff des Beitrags: 

Der Vorschlag ist nicht schlecht aber nicht anwendbar, ich sage nur deferred rendering, da versagt dein Vorschlag völlig oder andere nette Techniken die auf geometrie,post- und pre-shader und ähnliches basieren.
Entweder zeichnet das Plugin oder das Framework, was dazwischen ist murks und führt nur zu ungewollten abhängigkeiten.
Der Gang wird vom Framework dargestellt und alles was in einem Raum passiert muss von dem Plugin dargestellt werden, sonnst geht das Konzept nicht auf.
Man kann allerdings die Meshinformationen, für eine Tür, zur verfügung stellen, damit das Plugin dann entsprechend die Daten verarbeiten kann und darstellt.

Wer sagt denn eigentlich, dass auf der anderen Seite auch die gleiche Tür sein muss und nicht vieleicht ein Portal oder ähnliches den Heimweg verfügbar macht. Im Prinzip wird doch nur eine Funktion bereit gestellt, die dem Framework sagt, ich bin fertig, lass mich wieder in den Gang, woran diese Funktion gekoppelt wird ist des Plugin seine Entscheidung. Wenn der User ein Benchmark machen will, dann wird er bei Frame 1337 halt die Funktion aufrufen, bei einem Pakur wird halt ein Raumtrigger die Funktion aufrufen und so weiter.

Mitlerweile bin ich der Ansicht, alles was zum zeichnen und aggieren im Gang gebraucht wird sollte im Framework implementiert werden und abgeschalten, wenn es zum Plugin geht. Wenn im Gang halt glBitmap,Ode,FMod zum einsatz kommen soll, dann rein damit und fertig. Das Plugin kümmert sich selber um Sound, Texturen, Physik und co. Also der Ursprüngliche Gedanken, wenn ich es richtig interpretiert habe. Ich würde sogar soweit gehen und sagen, die Libs, die im Framework verwendet werden brauchen nicht dem Plugin bekannt gemacht werden. Damit würde man nochmal ne ganze Ecke Zeit sparen(bei der entwicklung des Frameworks). Wenn ich ein Plugin schreibe verwende ich z.B. Lua,MyDDS,OpenAL,Ogg und mein SceneGraph mit passendem Fileformat.

Autor:  oc2k1 [ Sa Mär 01, 2008 16:12 ]
Betreff des Beitrags: 

ICh denke eines der grösten probleme ist hier, dass teilweise wieder auch ähnliche demos in engines verwiesen wird, in denen jedoch nur content dargestellt wird.

Fakt ist, das gewisse verhaltensregeln beachtet werden müssen:

Fenster oder Blick durch eine offene tür:
Die physik muss vom hauptprogramm berechnet werden. Sollten spezielle resourcen wie Texturen (z.B in bildschrim größe) für rendertargets benötigt werden sollten sie zwischen den einzelnen räumen gesheart werden, da sonst die resourcen verschwendung schnell den kompletten VRam auffrist. Sauberes trennen des renderings ist mit einer stencilmaske des backbuffers möglich.

Innerhalb eines raumes:
Es gilt teilweise immer noch die pysik der umgebung. z.B. kollisionen mit den raum außengrenzen.

Portal:
startet quasi ein neues programm, die rückkehr kann bei programierfehlern unmöglich werden....

Frei plaziert:
Die arbeit des einzelnen wird im Gang plaziert. Die beste lösung für die jenigen, die keine eigenen renderverfahren benötigen oder nur ein model zeigen wollen.

Interaktion zwischen den räumen:
In einer engine wäre es möglich das shadowmaps und lichter unabhängig von den räumen sind. Spätestens wenn aber stencil shadow und shadowmaps vermischt werden und dann auch noch grenzen zwischen verschiedenen renderen überbrückt werden müssen bricht völliges caos aus, da sich die nötwendigen automatisch generierten shader aus dem produkt der in den einzelen räumen verwendeten shadern zusammen setzt....

Autor:  Finalspace [ Mi Mär 19, 2008 10:45 ]
Betreff des Beitrags: 

Leute ich würde vorschlagen,

damit das ganze einfacher zu realisieren ist, sollte man paar richtlinien festlegen wie z.b.

- Raumgrösse ist festlegt und ist nicht veränderbar, allerdings kann man wählen zwischen kleinem, mittleren oder grossen raum,
somit keine portale.

- Jeder raum bekommt seine eigene Rendereinstellungen, daher wenn im gang vor der tür shader benutzt wurden, dann sind diese nicht mehr wirksam im jeweiligen raum (Aber auf der tür schon), selbst texturen sind deaktiviert im raum.

- Jeder raum muss sich um texturen/shader/meshes etc. selbst kümmern.

Da jeder raum eine Initialierungsmethode, sowie eine Berechnungsmethode (pro frame) und eine render methode.
Plus natürlich eine Release methode zum freigeben vom dem kram :P

- Physik sollte im hauptprogramm so einfach sein wie möglich (Simple ego shooter ansicht mit einfacher kollision, eventuell möglichkeit treppen zu laufen)

Eventuell als idee, damit man es überhaupt keine problem gibt, sollten wir eine simple optimierung per PVS machen (Sone art portale).
Die türen selbst sind nicht direkt im korridor, sondern gehen erst ein stückchen mit ner kleinen treppe in die tiefe, soweit das der jeweilige raum vom flur und anderen räume getrennt wird.

- OpenGL wird vollständig von der Hauptapplikation bereitgestellt (Framework), fürs erste sollte OpenGL 2.0 reichen, das sind schon genug gl methoden die man implemtieren müsste.

Das würde so aussehen in einer raum dll:

Code:
  1.  
  2.  
  3. library myroom;
  4.  
  5. interface
  6.  
  7. implementation
  8.  
  9. uses dglrenderer, dglroom;
  10.  
  11. var
  12.   Renderer : TDGLRenderer = nil; // GL Framework
  13.   Room      : TDGLRoom = nil; // Informationen über den raum, sowie mesh infos zum füllen für physik
  14.  
  15. function InitRoom(_Renderer : Pointer; _Room : Pointer);
  16. var
  17.   NewPolys : array of TDGLPrimitivePolygon;
  18. begin
  19.   Renderer := TDGLRenderer(_Renderer);
  20.   Room := TDGLRoom(_Room);
  21. end;
  22.  
  23. function DrawRoom() : Boolean;
  24. begin
  25.   Result := False;
  26.   if not Assigned(Renderer) then Exit;
  27.  
  28.   with Renderer do
  29.   begin
  30.     ... normale gl statements
  31.   end;
  32.  
  33.   Result := True;
  34. end;
  35.  
  36.  

Autor:  Nils [ Di Mär 25, 2008 14:38 ]
Betreff des Beitrags: 

Ich denke es ist nun genug Zeit vergangen in der keiner was dazu gesagt hat. Sollen wir die Vorschläge nun so belassen oder hat jemand noch Einwände, denn sonst würde ich das bei Gelegenheit mal zusammenfassen und posten.

Autor:  Lord Horazont [ Di Mär 25, 2008 15:51 ]
Betreff des Beitrags: 

Nun, keine Proteste von daher...

Gruß Lord Horazont

Seite 6 von 6 Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/