Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Mo Nov 30, 2020 02:55

Foren-Übersicht » Sonstiges » Community-Projekte
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 86 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4, 5, 6

Habt ihr Lust auf so ein Projekt ?
Kein Interesse 6%  6%  [ 1 ]
Nur anschauen 35%  35%  [ 6 ]
Ich möchte einen Raum erstellen 24%  24%  [ 4 ]
Ich möchte beim Framework helfen 18%  18%  [ 3 ]
Ich möchte helfen und einen Raum erstellen 18%  18%  [ 3 ]
Abstimmungen insgesamt : 17
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 29, 2008 18:13 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
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

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 29, 2008 19:40 
Offline
DGL Member

Registriert: Di Jun 06, 2006 09:59
Beiträge: 474
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.

_________________
Bild


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 29, 2008 19:48 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 2023
Programmiersprache: C++
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.

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 29, 2008 20:54 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
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

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 29, 2008 21:50 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 17, 2005 13:19
Beiträge: 98
Wohnort: Jahnsdorf
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 ;-)

_________________
Administrator of Project Omorphia
Bild


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 29, 2008 22:02 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Okt 03, 2007 14:22
Beiträge: 388
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.

_________________
Meine Musik: spiker-music.net


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Mär 01, 2008 15:20 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2576
Wohnort: Berlin
Programmiersprache: C/C++, C#
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.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Mär 01, 2008 16:12 
Offline
DGL Member
Benutzeravatar

Registriert: So Jun 04, 2006 12:54
Beiträge: 263
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....

_________________
Lumina plattform unabhängige GLSL IDE


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Mär 19, 2008 10:45 
Offline
DGL Member

Registriert: Mi Okt 16, 2002 15:06
Beiträge: 1012
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.  


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Mär 25, 2008 14:38 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Okt 03, 2007 14:22
Beiträge: 388
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.

_________________
Meine Musik: spiker-music.net


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Mär 25, 2008 15:51 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Nun, keine Proteste von daher...

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 86 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4, 5, 6
Foren-Übersicht » Sonstiges » Community-Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 3 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.118s | 16 Queries | GZIP : On ]