Ja Tach auch ... also ich hab da n paar, ich sach mal, "kleine Schwierigkeiten" also eher Monströse Schwierigkeiten! Ich bin dabei schon seit ca. 2 Monaten oder mehr ich weis es nich mehr, ne 3D Engine zu basteln. Nach einigen harten Wochen und durchkämpften Nächten isses mir auch schon gelungen ein brauchbares Grundgerüst mit den notwendigsten Funktionen zusammenzustellen auch Sound (wobei daß das einfachste war) und bla bla bla.... Aber ich hänge da an ner Sache fest die mich schon nich mehr schlafen läßt! BSP-trees!!! Ich hatte es so geplant das ich als Modelle md3s verwende und BSP files für die Level ala Quake3 oder Halflife weils ja schon das gängigste is und es auch sehr gute Editoren dafür gibt, weil noch nen Leveleditor mit nem eigenen Dateiformat zu basteln.. da bin ich ja dann alt und grau bis das ma lübbt So nun hab ich mir schon fast alle Tutors über BSP-Trees usw eingepfifffen (die meisten auch wirklich verstanden) aber irgendwie bin ich nich in der Lage das in brauchbaren Code umzusetzen natürlich gallt mir als Anhalt das BSP-Tutor mit Source von Jahn Horn ( der war einfach genial der Mann) aber das is ja nur n Tropfen auf dem heißen Stein! Sowas wie Lightmaps und PVS und frustumculling und so das is darin ja nich vorhanden. So dann hab ich die convertierung ner BSP unit von c nach Delphi gefunden von Joachim de Vries welche auch wirklich top is aber leider auf DirectX gemünzt ist und da ich da auch keinen Peil von habe (wie von so vielem fällt mir grad mal auf *ggg* ) hab ichs auch nich auf die Reihe gekriegt das für OpenGl umzubauen ausserdem will ich ja auch nich den code von anderen klauen um den in meine Projekte einzubauen ( wo komm wa da denn auch hin??? ). Auch ne BSP Unit die Culling und die Aufteilung in Portale usw enthielt hat mich nich weitergebracht weil die war in C und wie ihrs sicherlich erahnen könnt ... keinen Plan von C!!! Klar gibts auch andere BSP units in Delphi zu der Geschichte aber die sind dann auch wieder mit irgendwelchen Komponenten verknüpft welche die ganze Grafikarbeit und so leisten und danach steht mir ja auch nich der Sinn. Also steh ich nach unzähligen gescheiterten Versuchen wieder bei 0 da bei dem Thema. Daher meine Frage.. wer kennt sich damit aus .. oder hat nochn besseres Tutor als die von Gametutorials oder flipcode oder sonst wem, oder hat das schonmal gemacht oder davon gehört oder geträumt und kann mir da weiterhelfen (kleiner Wink mit dem Zaunpfahl : vielleicht wirds Zeit fürn kleines Tutor von DGL *ggg* Ne nur Spaß). Aber ich wäre echt um jede Hilfe dankbar!!! <cya>

_________________
...and don't forget .. real coders don't write specs!!!

@tutorial: Wenn Du es soweit schon begriffen hast, vielleicht kannst ja selbst eines Schreiben um den Einstieg für die Leute zu gewährleisten oder zumindest den Grundstein zu legen... frei nach dem motto ich begeistere einige Leute, vielleicht lernen die schneller als ich *gg*

Der Source von JDV wird wohl auch der beste anhaltspunkt sein. Sonst einfach mal JDV anschreiben, wird sicherlich behilflich sein Und notfalls... *vorgehaltene.hand* Er leidet an Konvertierungs-Wahn

Mir ist momentan sonst niemand bekannt, der sich damit ausgiebig befaßt hat.... vielleicht noch Son OF Satan, der mit seiner Zorn-Engine vielleicht schon Erfahrung hat!

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

erstma danke für die prompte Antwort..

@tutor ... naja wenns mal irgendwann was werden sollte könnte ich echt mal darüber nachdenken. Ich finds gut wenn ich auch anderen damit helfen könnte aber bevor ich mich da ran traue wirds wohl nochn bischen dauern

@JDV ja das wäre ne möglichkeit müsste ich einfach mal ausprobieren


THX

_________________
...and don't forget .. real coders don't write specs!!!

Promt? Fast 20 min später, dass ist unter DGL Schnitt


Naja, vielleicht ja auch nur ne Einstieg. Ich denke, dass ganze in einem zu machen wäre schon fast totschlag Einfach mal drüber nachdenken, den zumindest soweit ich weiß, kann man das ganze schön in vile kleine Glieder teilen und immer wieder ergänzen... aber gut... ich habe keinen Plan davon. Einfach mal im Hinterkopf behalten


Si... beißen tut er nur selten und ist ja auch mitglied hier im Forum, meist treibt er sich auch bei den neobrothers noch rum

Ce

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Jaja...BSP-Bäume sind schon so ne Sache, und wenn dann noch Geometrieoptimierungen wie PVS dazu kommen, kann's manchmal doch schon ganz heftig werden.

In meiner ZornGL-Engine gab's auch mal BSP-Bäume.Aber ehrlich gesagt sind die Dinger (meiner Meinung nach) am Aussterben, da sie viel zu prozessorlastig sind.Oft werden BSP-Bäume nur noch zur Kollisionsabfrage implementiert, da man so viel Rechenzeit einspart und unnötige Polygone aus dem Kollisionstest rausläst.
Aber auch dafür hab ich in meiner ZornGL eine andere Lösung gefunden...
Wer also BSP in seiner Engine nutzt, verschwendet viel Potential moderner Grakas, da ein großer Teil der Berechnungen dann immernoch auf der CPU gemacht wird.

Die einzige richtige CPU-Geometrieoptimierung meiner Engine ist Frustum Culling, und das ist so ziemlich das einfachste an ner Engine.Die Unit für's Frustum Culling meiner Engine hat maximal so um die 200 Zeilen...wenn Interesse besteht und ich Lust dazu habe, dann werd ich vielleicht mal den Frustum-Culling Abschnitt aus der Dokumentation zu meiner Projektarbeit hochladen.

Zum Editor :
Einen Fremdeditor (wie z.B. QERadiant) zu nutzen ist natürlich einfacher als selbst einen zu schreiben.Aber ein eigener Editor lohnt sich früher oder später, besonders wenn man Dinge in die Maps einbringen will, die man mit QERadiant nicht machen kann.Ausserdem hat man dann einen Editor, mit dem man alles machen kann, und nicht dutzende Tools, mit denen man die Maps nachbearbeiten muss.
Wenn du also nen eigenen Editor proggen willst, dann mach's so wie ich und programmier denn vor deinem Game, und zwar so modular das die Grundlage für den Editor auch als Grundlage für das Spiel dienen kann...das hab ich auch gemacht, und es hat mir sehr viel Arbeit erspart.

Oder schau einfach mal unter <a href='http://www.gamefortress.com/~delgine' target='_blank'>http://www.gamefortress.com/~delgine</a> , das ist auch ne geile, in Delphi programmierte Engine mit nem kompletten Editor, dessen Kartenformat offen ist.

Aber falls trotzdem am Q3-Map Format Interesse besteht, auf folgender Page gibt's nen Q3-BSP-MAP-Loader inklusive Lightmaps :
<a href='http://www.sibvrv.km.ru/' target='_blank'>http://www.sibvrv.km.ru/</a>

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

danke danke danke danke und nochmals danke ...

Also das sind schonmal gute infos. Das mit der hohen prozessorlast hab ich nich gewusst und natürlich besteht .. auf jedenfal von meiner Seite aus Interesse an der Frustum Culling Geschichte.. wäre echt cool und würde mich bestimmt ne ganze ecke weiter bringen...

_________________
...and don't forget .. real coders don't write specs!!!

Wenn Du dann immer noch Probleme mit BSP-Trees hast, schau doch mal bei Steffan Zerbst nach. Das ist zwar mit Direct3D und C/C++, aber die Theorie ist durch aus verwendbar. (www.zfx-online.de)

@Son: Was ist außer BSP-Trees Deiner Meinung nach dann verwendbar?!? Wenn ich einen BSP-Tree hab' um Kollisions-Erkennung durchzuführen, wozu soll ich dann was anderes zur Darstellung verwenden? Und was gibt's anderes? Ist 'ne Portal-Engine weniger CPU-Lastig?

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Hab mir heute mal die Mühe gemacht und hab zum Thema Frustum Culling auf meiner Page ein Tutorial inklusive Quellcode und Beispielprogramm veröffentlicht.
Momentan gibt's das Tut aber nur in Englisch, werke aber gerade auch an der Deutschen Version meiner geupdateten Page, die ich vielleicht noch diese Woche hochladen werde.


Naja...selbst wenn man BSP zur Kollisionserkennung nutzt, kann man ja noch andere Methoden zur Geometrieoptimierung nutzen.Meiner Meinung nach sind dafür z.B. Octrees oder v.a. für Terrains Geo-MipMaps viel besser geeignet.
Auch PVS (Potentially visible Sets) sind meiner Meinung nach brauchbar!

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Brauchst du jetzt eigentlich Infos zu BSP-Trees (also Thema: Visibility Determination) oder für die Quake3 BSP Level ?? Das konnte ich nicht nicht ganz aus deinem Post herausfiltern. Beides hängt nämlich nicht zwangsläufig zusammen.

Ich muss Son Of Satan Recht geben. BSP-Bäume "sterben langsam aus", da sie sich am effektivesten für Visibility Determination für Indoor-Level eigenen (ala Quake3/HL und die ganzen älteren Shooter). Bei neuen Shootern gibt es ja mittlerweile fast nicht mehr die Unterteilung zwischen Indoor- & Outdoorszenen.

Falls du also nun ne Unit brauchst, mit der du Quake3 BSP Files reinladen kannst, kannste mir ma ne Mail schreiben, ich hab hier mal ne Unit dafür geschrieben. Jedoch beschränkt sie sich aufs Einladen der ganzen Infos. Aber das Einbauen in die eigene Engine sollte ja nicht so das Problem sein

Noch kurz zu Visibility D.: Du solltest dir Gedanken machen, welche Art von "Levels/Szenen" deine Engine beherrschen soll. Wenn du nur Indoor-Level hast (also ohne große Terrainberechnungen), dann wäre ein BSP -Tree evtl. sinnvoll. Wenn du z.B. hybride Szenarien hast (also Indoor & Outdoor zusammen), dann kann ich nur Octrees empfehlen (auch für die Kollisionserkennung echt 1A!!). Dann gibt's ja noch den ganzen Kram wie Potential Visibility Sets, Portale & Occlusion Culling, aber ich halte von den ganzen Dingern nicht soo viel. Ich kam zumindest nie an den Punkt, wo ich mit den Teilen eine wesentlich höhere FPS Zahl hatte, als mit Octree + Frustrum Culling.

So, das war mein Senf dazu
Viel Erfolg noch beim Programmieren deiner Engine ...

cyas

LordRaptor

_________________
3D Rollenspiel-Hobbyprojekt von mir.
Guckst du hier:
http://ip-web.ath.cx/superstition/

Ist ein Octree wirklich so gut für Indoor-levels geeignet?!? Ich dacxhte immer, dass er für diese eher nicht geeignet wäre. *verwirrt*

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Ein Auszug aus meinen vorherigen Posting:


Ich hoffe, damit ist die Frage geklärt
Noch zum Verständnis: Unter einem hybriden Szenario verstehe ich persönlich z.B. Terrain + Gebäude darauf. Am Intelligentesten wäre es natürlich, wenn du je nach Kameraposition zwischen verschiedenen Visibility Determination Algorithmen umschalten könntest. Sowas habe ich bisher jedoch nie in Aktion gesehn und das wird wohl noch ein wenig Zukunftsmusik bleiben

Der Kommentar zu PVS, OC usw. bezog sich nur auf meine persönlichen Erfahrungen. Diese beschränken sich größtenteils auf hybride Szenedarstellung, somit bin ich bisher mit Octrees & Frustrum Culling am Weitesten gekommen.

EDIT:
Um es noch einmal deutlich zu sagen: Indoor + Octrees bringt nicht viel, da es beim Octree ja darum geht, dass du quasi alle zu zeichnenden Dreiecke anhand ihrer Position in Sektoren einteilst und dann bestimmst, welcher Sektor für die Kamera überhaupt sichtbar sein kann. Da aber bei Indoor Leveln ja meistens Wände die begrenzte Geometrie sind, sollte man andere Verfahren vorziehen.

_________________
3D Rollenspiel-Hobbyprojekt von mir.
Guckst du hier:
http://ip-web.ath.cx/superstition/

Kannst Du mal mitteilen, wo's für die Octrees die bestens Infos gibt (geht auch für C/C++). Mich würde nämlich interresieren, wie man Collision-Detection damit macht. Das Grob-Prinzip von Octrees kenn ich einigermaßen.

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Auf <a href='http://www.gametutorials.com' target='_blank'>http://www.gametutorials.com</a> gibts dazu einige "Tuts" mit C++ Quellcode.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

@lordraptor
.. also die engine sollte eigentlich für outdoor levels also terrain und n paar gebäude und son zeux sein (sonst kann ich meine schönen skybox textures ja wieder wech schmeißen *lol*) und irgendwie bin ich nu n bischen verwirrt jetzt hab ich hier zig möglichkiten bzw. techniken gehört aber für die richtige kann ich mich da irgendwie nich so entscheiden bzw. da fehlt mir dann auch wohl das know-how zu.
Würde denn portal-rendering auch für son scenario funzen und das mit den q3 bsp-files fand ich eigentlich auch ganz nett, ok das ich um frustum-culling wohl nich drumherum komme das leuchtet mir ja schon ein aber bei allem anderem steh ich da wie der sprichwörtliche Ox vorm Berge.

_________________
...and don't forget .. real coders don't write specs!!!

Ich hab' mich mal umgesehen. Auf FlipCode gibt's was zum Thema OcTree. Allerdings ist mir schleierhaft, wie man damit Collisions-Erkennung laufen lassen kann. Aber schau Dich mal um. Ich hab' nur Festgestellt, dass Octrees 'n witz sind, wenn man sich mal mit BSP-Trees beschäftigt hat. Die Octrees sind viel einfacher. Zumindest von der Theorie

Ich hab' mir aber auch schonmal überlegt, OcTrees und BSP-Trees zu mischen. Wird IMHO auch im ein oder anderen Game gemacht. Blos, ob sich der Aufwand bei den heutigen Rechnern lohnt? Das, was man evtl. als Geschwindigkeits-Verlust durch Octrees hat, kann man wohl mittlwerweile echt vergessen

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?