Hallo liebes GM-D Forum.

Ich hätte da wiedermal eine Frage bei der ich evtl Hilfe von experten bräuchte.
Es geht darum dass sspäter mal gerne eine Art 3D Editor schreiben würde.
Was für mich dabei eine hürde darstellt ist das auswählen von Objekten im 3Dimensionalen Bereich.

Man kennt das ja schon von verschiedensten Editoren: Man klickt mit der maus auf ein Bauteil und dieses wird ausgewählt.
Das Problem für mich ist nun, wie man sowas überhaupt umsetzen könnte (ohne stark auf die Performance zu drücken)

Ich kann mich noch gut an ein example von Moolt errinern wo dies abgehandelt wurde. Dabei wurden die Blöcke die man anklicken konnte in einer 2ten View ( die für dne Spieler unsichtbar ist) gedrawt. Dabei wurde jedem Block eine Farbe zugewiesen die einzigartig war ( sprich: die nur einmal in der speziellen view vorkam).
Anhand eines arrays das zuvor erstellt wurde (beinhaltete die Farbe und die zugehörige Objekt-ID) konnte man feststellen auf welches Objekt der spieler gerade zeigt.
Man nahm einfach den jeweiligen pixel vom bildschirm auf dem die Maus war und vergleichte mit der Farbe den inhalt des "Farb-Arrays". So konnte man auf das Objekt schließen.

Die Frage: Geht es auch anders? Ich kann mir gut vorstellen dass bei komplexeren Strukturen das ganze etwas lahm werden könnte (sprich: bei vielen Objekten).
u.a. da dass draw-event pro objekt 2 mal ausgeführt wird. 1 mal das "normale" modell, und das 2te mal die gefärbte Version.

Was für möglichkeiten gäbe es denn so etwas performant hinbekommen? Welche Ansätze gebe es denn?
Wie realisieren dass überhaupt andere Programme wie z.B: Blender wo man allein jeden Vertex anklicken kann? (Ich nehme mal an die nutzen irgendein Raycasting Verfahren ...)

Du könntest auch diese kollisions-DLL probieren welche insbesondere Raycasting unterstützt:

Werde ich mir mal anschauen. Wobei ich ungern auf eine DLL umsteige die ein Projekt so stark abhängig von deren Funktionalität macht.

EDIT: Übrigens könnte man Moolts Variante vieleicht noch ein klein wenig beschleunigen indem man statt einen weiteren View, eine Surface benutzt auf der diese farbigen Versionen gedrawt werden (dies ist seit der EInführung eines Z-Buffers im GM 8.1 möglich).

Was wäre der unterschied wenn man draw-getpixel direkt von der view oder von einer Surface aus aufruft? Die blöcke selber müssen auf die Surface selber mit screen_redraw gezeichnet werden. Die Draw-Calls werden dadurch nicht weniger. Oder meinst du die geschwindichkeit des draw-getpixel aufrufes? ( da es nur einer per step ist, fällt der aber so gut wie garnicht ins gewicht.)
Vielleicht übersehe ich aber auch etwas.

(dies ist seit der EInführung eines Z-Buffers im GM 8.1 möglich)

? Ich bin jetzt verwirrt. Den Z-Buffer gab es doch sicher schon früher seit der GM6er Version. (war ja glaub ich der erste GM der 3D unterstützte.)
Für 3D Darstellung ist ja ein Z-Buffer nötig sonst könnte man ja die Tiefenunterschiede im 3Dimensionalem Bereich (sprich: unterscheiden ob ein objekt vor oder nach einem Objekt kommt.) nicht erkennen. (also die engine selber)
Was allerdings nice wäre ist ein Frame-Buffer auf den man direkt zugreifen kann. Bis dato musste ich mir diese anhand von Surfaces selbst "programmieren" was aber performanceseitig nicht gerade optimal ist. (insbesondere bei höheren Auflösungen.)

Iwie mag ich es solche Diskussionen zu führen.

Exactly. Ich brauche keine "Quick and dirty" 0815 Lösung die ich innerhalb von 10 Minuten zusammenschustern kann. Ich bräuchte etwas was stabil, funktional und performant sei.

Die U3D Engine wird soweit ich weiss garnicht mehr weiterentwickelt. Der Programmierer wollte sie "standalone" machen (nicht mehr vom GM abhängig) aber was daraus geworden ist...
Die Ogre Engine wäre zwar auch eine Möglichkeitm aber ich weiss nicht ob sie aktuell überhaupt mit dem GM8.1 stabil läuft. Sie wurde zwar portiert, aber soweit ich sah auch nur "provisorisch".
(und ich habe nicht gerade die Zeit/Lust im Laufe der Zeit auf Probleme zu stoßen die auf die inkompaktivilität bzw auf Bugs der Engine zurückzuführen sind die sich nicht durch mich lösen lassen... Habe sowas schonmal erlebt...)

Ich brauche ja auch nicht diese extra Funktionen die mir GMOgre bietet. Das einzige was ich brauche ist eine Möglichkeit Objekte im 3D Raum per Maus anzusprechen.
Wobei es all den anschein hat dass die Farbmethode die beste wäre.

Und aus Prinzip keine externen libs zu verwenden, ist eine unnötige Beschränkung.
Das ist, als wenn man keinen Akkuschrauber verwendet, sondern die 90 Spax lieber per Hand reindreht. Viel Spaß dabei

Das stimmt nicht ganz. Ich verwende durchaus DLLs. Ich bin blos bei denen Vorsichtig auf denen meine Projekte gestützt werden würden.
Sprich: Situationen bei denen das versagen der DLL (in irgendeinem Fall) zu einem unlösbaren Problem (und damit zum scheitern des Projekts) führen könnte, will ich vermeiden.
Hingegen DLLs die "sekundär" sind (Sprich online Highscore oder irgendwelche File DLLs) kann man im Notfall durch andere ähnliche DLLs oder durch die internen GM funktionen ersetzen.
Wenn es wirklich nicht anders geht, kann man diese Problemlos entfernen. Das Spiel ansich wird dadurch nicht beeinträchtigt da die DLL nicht im Kern des Systems sitzt.

Solche (ich sag jetzt mal "riskanten") DLLs kann ich durchaus für experimente, Tests oder kleine Minigames verwenden.
Wenn es aber um meinen Kopf geht (*hust* Schule *hust*), Spiele ich doch lieber in der Safezone um Probleme zu vermeiden die für mich einfach unlösbar wären. (Giltet auch für "größere" Projekte wo ich mir solch einen Bug nicht leisten kann.)

Bei DLLs die ich selber schreiben würde (wenn ich es denn könnte) würde die Sache ja schon wieder anders aussehen da für mich die Möglichkeit des debuggins gegeben wäre.