Ideensammlung für Train Fever Nachfolger

So sieht bei mir ein Überholbahnhof aus. Erklärt hab ich es ja schon oben.

Wie wäre es denn wenn die Geschwindigkeiten und Positionen der Fahrzeuge etwas im Vorraus berechnet werden würden?
Dann könnte man den Linien Prioritäten geben und ggf. noch Hauptstrecken mit einbringen auf denen Fahrzeuge unabhängig von der Linienpriorität immer Vorfahrt haben.
Falls ein Zug mit höherer Priorität auf einen mit niedrigerer Priorität warten müsste, darf der Zug mit der niedrigeren Priorität den Gleisabschnitt eben nicht befahren, sondern muss am Signal warten.
Wäre natürlich die Frage wie viel Rechenleistung das kostet. Prinzipiell dürfte es kein großes Problem sein sowas zu berechnen. Muss man halt mal die Mathematik nach Hilfe fragen.

Was mir bei "TF2" vorschwebt ist eine Anzeige, nachdem beurteilt wird, inwieweit ein Mod bzw. die Anzahl der SIMs das entsprechende System belastet und zu Performance-Aussetzern führen kann..

Zitat von BR84

TF2 ist dermassen systembereinigt, da ruckelt nix mehr.

I hope so.
Nein - so eine Anzeige müsste natürlich nach Laden des Mods deren Inanspruchnahme beurteilen - und das lässt sich leider nicht immer so locker einschätzen.
Nichtsdestotrotz hast Du natürlich dahingehend Recht, dass die Anzeige in der Nähe hoher Performanceansprüche (wie z.B. vieler paralleler Gleise) deutlich einbricht und man auch das berücksichtigen sollte...

Man kann sicher viel Performance sparen, wenn man alles "out of view" etwas nachlässiger berechnet. Ich hab leider keine Ahnung, wie das bisher schon gemacht wird, aber wenn ich durch einen Berg "hindurch" schaue auf die Map dahinter und plötzlich is Diashow angesagt, spricht das mMn Bände >< Solange der Sichtliniencheck (ich -> Gelände -> Objekt) deutlich weniger Leistung beansprucht wie die Objekt-Berechnungen, kann das viel helfen *denk* Ein Fahrzeug hinterm Berg braucht nicht visuell berechnet zu werden. Ausrichtung, Meshdaten, Texturen... Was weis ich Oder allein schon die Darstellung auf der Straße. Muss das Fahrzeug grad warten? Sowas kann man mit nem rudimentären Code umsetzen. Beispielsweise ist in der Stadt grad viel verkehr und die Durchschnittsgeschwindigkeit sinkt. Alles nur statistische Hochrechnungen. So und so viel Strassen-Länge bei so und soviel Autos macht im statistischen Mittel Stau und 20kmh in der ganzen Stadt. Also fährt das Fahrzeug gerade nur 20kmh die ganze Zeit. Sieht man eh nich Und warum der Hickhack? Damits wenigstens einigermaßen realistisch bleibt. nich dass die Stadt vollkommen dicht ist, die eigenen Linien machen Nasse weil sie nur stehen und dann schaut man halt weg, es wird nich mehr so genau berechnet und alles flutscht plötzlich wieder. Darf ja auch ned sein. Aber was man nicht sieht, kann man durchaus mit Näherungswerten berechnen.

Zitat von BR84

Solltest du zusätzliche Leistung durch Aktivierung zusätzlicher Erweiterungen beanspruchen wollen (Mods heisst das glaub ich), können wir nicht mehr für reibungslosen Ablauf garantieren.

Nur: Von Mods lebt zumindest TF1 - aber man möchte sie auch einschätzen können.
Und versprochen worden ist mit vielen Updates (gerade in Hinsicht auf die Performance) viel - was wirklich gehalten wurde, muss jeder für sich selber entscheiden...

Sie werden ganz sicher viel gelernt haben. Das größte Problem wird wohl aber sein, dass zu einem gewissen Grad nur theoretisch Wissen angehäuft wurde und dieses nun praktisch umgesetzt werden muss.

Was ich meine ist folgendes: Sie haben ihr TF1 wie es eben ist. Sie haben erfahren an welche Grenzen das von den Spielern getrieben wird. Beim Versuch diese Grenzen zu erweitern haben sie ganz praktisch erfahren, wo wirklich die Grenzen liegen. Und vorallem wodurch diese zustande kommen. Das sind aber oft Dinge, die so tief verwurzelt sind, dass man das Spiel gleich neu aufsetzen könnte.

Nuja, und da sind wir ja gerade Allerdings sind die neuen Methoden eben wieder nur Theorie. Sie werden sicherlich die alten Probleme grundsätzlich angehen und das von Vornherein angepasst aufziehen. Aber wird es DIE Lösung sein? Ich vermute ganz dezent nein Bessere Performance schaft bessere Möglichkeiten und die werden User-seitig sicher wieder bis ans Limit getrieben Wie flexibel der neue Code auf diese Belastungen eingehen kann, wird erst die Zukunft zeigen.

Das sind natürlich alles nur Vermutungen, aber ich find sie recht plausibel. Wenn es wirklich noch besser wird, hab ich freilich nix dagegen

"Eigentlich" ist eine Transportsimulation ganz einfach, aber wahrscheinlich deswegen so kompliziert.

Jede Simulation besteht doch aus
1) einer Basis (bei TF: Karte aber eigentlich schon 3D also eher ein Quader)
2) an die Basis werden Spuren (Lanes) geheftet. Bei TF sind das Straßen, Schienen, Fußwege. Warum nicht auch Flüsse, Luftkorridore, Röhren? Warum keine Fußwege beliebig auf der Karte (Berge für Bergsteiger, Schwimmbäder für Sims)?
3) an die Spuren werden über einen oder mehrere Andockpunkte Transportmittel geheftet. Dies sind bei TF Eisenbahn, Fz, Tram, Sims, Güter aber im Prinzip wären auch Schiffe, Flugzeuge, Raketen, Fahrräder denkbar. Man muss nur die Parameter und das Aussehen ändern.
4) Und dann gibt es noch Objekte, die nicht (oder nur durch die KI) gesteuert werden.
a) Diese können wahlfrei auf der Karte platziert werden (Bäume),
b) spurbezogen (Signale) oder
c) transportmittelbezogen (Anhänger)
d) Auch Objekte, die im Bezug auf andere Objekte platziert werden können, sind denkbar. Dann kann man z.B. Telefonzellen auf dem Standardbahnhof abstellen.
5) An die Transportmittel können auch
a) andere Transportmittel geheftet werden. Bei TF sind das Sims und Güter. Warum nicht auch Autos (Autozüge),
b) Spuren (Eisenbahnfähren, bei denen der Zug auf die Fähre rollt, Autozüge mit rollenden Fahrzeugen und Personenzüge, in denen die Sims auch tatsächlich zu ihrem Platz laufen)
b) Objekte (Lichterketten am Weihnachtszug, Schnee, Schneepflug)

Jedes Objekt hat bestimmte Eigenschaften, die modbar sind (Lage, Geschwindigkeit, Geräusche, Aussehen, Andockpunkt(e) mit Karte, Spuren, Transportmuttel, Objekten, Umwelteinflüsse).
All das wird gesteuert durch Entscheidungen (manuell durch den Spielers, seines Fahrplans und der KI) bzw. Ereignissen.

Somit könnte man Spuren aufs Dach legen und Sims vom Typ Dachdecker finden dann endlich einen Arbeitsplatz.
Kleidung könnte die Standardladung eines Sims sein aber durch Laden eines Gutes vom Typ "Badehose" kann der Sim auch die Spuren (Bahnen) im Schwimmbad nutzen.

Mit so einer Basis könnte man endlos modden. Und das ist wahrscheinlich auch das Problem, denn damit wäre der Spieleentwickler arbeitslos. Und wahrscheinlich sind die Freiheitsgrade so groß, dass die Performance in den Keller geht, Also müssen wir mit den Einschränkungen der Spieleentwickler leben oder warten, bis es CPUs gibt, bei denen jedes Objekt einen eigenen Prozessorkern bekommen kann.

P.S. Wahrscheinlich bin ich vom Thema abgekommen, war aber lustig, mal drüber nachzudenken.

Mir gefällt deutlich, dass mal jemand einen LKW im Spiel nicht unumstößlich als LKW bezeichnet sondern das ganze runter abstrahiert Balsam für die Seele

Im Endeffekt kann man alles was mit dem Transportnetz zu tun hat auf Graphen runter brechen.
Es gibt nur (unterschiedliche) Knoten (Halte, Signale und Abzweigungen) und die Verbindungen dazwischen (Kanten), die unterschiedliche Attribute haben (z.B. Wegtyp, vMax, Trassenkosten)
Je nachdem wie man es betrachtet, könnten Signale auch als Knoten wegfallen und nur in der "wie schnell kome ich von Knoten A nach B Logik" enthalten sein.
Stationen sind allerdings immer Knoten, da diese schließlich ein "Abzweig" von Gleisen auf den Fußweg sind.

Hat man erstmal ein solches Netz aufgebaut, kann man auf diesem Linien definieren und daraus wieder einen neuen Graphen bauen. von jeder Station aus kann auf den Fußweg "umgestiegen werden. Die Fußwege sind allerdings die einzigen "Linien" die nicht im Graphen gespeichert sein sollten, da diese doch recht viele sind (von jeder Station zu jeder anderen Station und jedem Haus vorrausgesetzt alle Städte sind mit Straßen verbunden)

Am Ende kann man dann auf dem Liniengraphen mit einem kürzester (bester) Pfad Algorithmus die beste Verbindung heraussuchen. Hierbei muss man wissen zu welcher Zeit man startet und wann welches Verkehrsmittel an welcher Station sein wird.

Btw. liegt genau hier der Faktor der große Transportnetze extrem langsam macht, was durch sehr große Städte (viele Einwohner) noch begünstigt wird. Eine solche Suche benötigt nämlich größenordnungsmäßig eine Zeit von mindestens O(n*log n + m), wobei n die Anzahl der Knoten ist und m die Anzahl der Kanten. Das heißt also der Aufwand liegt irgendwo zwischen einem linearen und einem quadratischen Aufwand.

Ich vermute mal im aktuellen Simutrans wird das auch so in der Art umgesetzt.

Jetzt aber nochmal zurück zu den Prioritäten. Ich spiele aktuell man wieder ein wenig Simutrans und da gibt es die 2 Block Signale. Das System funktioniert ähnlich wie die Idee von @Yid bzw. @Grimes, allerdings Streckengebunden anstatt Fahrzeug oder Liniengebunden, was in den meisten Fällen wohl auch sinnvoller sein dürfte.
Ein 2-Block Signal reserviert einfach die nächsten 2 Blöcke, anstatt nur einen. Ich würde es allerdings lieber sehen, wenn man bei jedem normalen Signal einfach einstellen kann wie viele Blöcke es blockieren soll, wenn es überfahren wird anstatt dieses als spezielles Signal zu implementieren. Man könnte dann in einem an und ausschaltbaren Signal Layer die entsprechende Zahl über den Signalen einblenden o.ä.)
Die Idee gefällt mir zwar nicht ganz so gut wie meine andere, dürfte aber eine ganze Ecke einfacher zu implementieren sein und in den meisten Fällen mehr Sinn ergeben als die reservierten Blöcke fest an die Linien oder gar Fahrzeuge zu binden.

Es gibt da nur ein Problem: Es wird auf der Strecke dann jeder Zug priorisiert, im Zweifel der Güterzug vor dem ICE... (Stell dir die Vereinigung Zweier Schnellfahrtrassen vor, auf denen auch Güterverkehr unterwegs ist)

Zitat von Freahk

Im Endeffekt kann man alles was mit dem Transportnetz zu tun hat auf Graphen runter brechen.
Es gibt nur (unterschiedliche) Knoten (Halte, Signale und Abzweigungen) und die Verbindungen dazwischen (Kanten), die unterschiedliche Attribute haben (z.B. Wegtyp, vMax, Trassenkosten)
Je nachdem wie man es betrachtet, könnten Signale auch als Knoten wegfallen und nur in der "wie schnell kome ich von Knoten A nach B Logik" enthalten sein.
Stationen sind allerdings immer Knoten, da diese schließlich ein "Abzweig" von Gleisen auf den Fußweg sind.

Achtung, Theorie bzw Halbwissen (als das Folgende meinerseits! ><
Knoten und Kanten kann man auch in Points und Edges übersetzen bzw generell in Vektoren. Und was machen Grafikkarten? Sie berechnen Vektoren Also sie sind auf die Arbeit mit Vektoren eben spezialisiert. Zudem sind sie hoch parallel angelegt usw usf. Ich glaube genau hierrin liegt dieser Vorteil von GPGPU Gedöhns oder? Wie gesagt, ich hab mich damit allenfalls theoretisch beschäftigt, falls hier wer fundiertes Wissen hat, freue ich mich drüber. Weil mir erschließt sich noch nich so ganz, wie man aus dem Graphen in der GPU wieder einen Nutzen fürs Programm erzielt

Also die Ideen, die mir dazu im Kopf rumschwirren, sehen derart aus:
Der Wege-Graph wird quasi als Mesh angesehen, mal ganz doof gesagt. Jedes Auto hat in TF schon 1000e Punkte (Knoten) und Kanten mit Texturen drauf und und und. Solch einen Graphen auf ner GraKa zu behandeln, sollte also hoch effizient sein. Stell ich mir so vor. Sprich, selbst die zig Fußwege sollten kein Ding sein. Die Kanten könnten nun je nach Geschwindigkeit darauf anders faktorisiert werden. Also Punkt 1 ist zwar von Punkt 2 genausoweit entfernt wie von Punkt 3 und die Kanten P1-P2 und P1-P3 sind auch noch in etwa gleichwertig im Sinne der Zielfindung (also nich eine in Richtung Ziel, die andere zeigt davon weg oder so), aber Kante P1-P2 ist doppelt so schnell passierbar wie P1-P3, also würde diese gewählt (sofern sie denn auch zum Ziel führt ). Nun müsste man aber halt irgendwie quasi das Graphen-Mesh ausdünnen, so das nur die gewünschte Strecke durch den Graphen übrig bleibt und den zurücksenden. Geht das? Da hab ich bisher keine Ahnung von ><

@BR146
Dazu kann man dann Ausweichgleise bauen, über die man Güterzüge gezielt mit Wegpunkten leiten kann.
Sollte es also zu dem seltenen Fall kommen, dass ein Güterzug auf der Hauptstrecke auf der auch ICEs fahren verkehrt und ein ICE von einer Strecke kommen sollte, die eben keine Vorfahrt hat, dann muss man eben die Hauptstrecke an dieser Stelle doppelt 2 Gleisig ausbauen, damit der Güterzug eben keine Vorfahrt hat. Das Ausweichstück würde man dann aber so oder so bauen, da man die Hauptstrecke auf der der Güterzug fährt schließlich nicht durch einen wartenden Güterzug verstopfen möchte. Schließlich könnte direkt dahinter ja auch ein ICE fahren der, da er auf der Hauptstrecke fährt Vorfahrt vor dem anderen ICE haben soll.

Ich kann mir so Spontan kein Szenario vorstellen, das man nicht mit einem Ausweichgleis lösen könnte (und auch keines bei dem die Variante mit mehrblock Signalen eine Ausweichstelle erforderlich* macht, die andere Variante allerdings nicht.

Ansonsten könnte man aber auch zusätzlich zu den Mehrblock Signalen den Linien eine Priorität (keinen Blockabstand) mitgeben, der im Falle von mehreren überschneidenden Mehrblocksignalen entscheidet wer am Hauptsignal** Vorfahrt bekommt.

Da das vielleicht etwas unverständlich klingt hier eine kleine ASCII Skizze mit Beschreibung:
Sn ist ein Signal das n Blöcke blockiert >, <, v, ^ die Fahrtrichtungen, o eine Weiche und - ein nichtssagender Platzhalter.

>>>>>S2>>>>>>>>S1>o>>>>>>>S1>>>
>>>>>S2>>>>>>>>S1>^

Beide Linien sind also erstmal von den Signalen her gleichwertig.

Auf der Oberen Linie fährt nun ein ICE mit Priorität 3, auf der unteren ein Güterzug mit Priorität 1 (je höher desto besser)

Der Güterzug überquert das 1. Signal und merkt erstmal den gesamten Bereich bis zum letzten Signal.
Der ICE überquert nun sein erstes Signal, blockiert nun den Bereich bis zum letzten Signal. Der Güterzug blockiert jetzt nur noch den Bereich zum 2. Signal. Hätte der Güterzug zu diesem Zeitpunkt bereits sein 2. Signal überfahren, müsste der ICE am 2. Signal halten, da der Güterzug bereits im gemeinsamen Bereich wartet.

Umgekehrt: Güterzug Oben überquert 1. Signal, ICE fährt unten funktioniert genau so. Der Güterzug steht nun also auf der geraden Strecke und blockiert diese bis der ICE hinter dem letzten Signal ist. Das würde bei dem anderen Vorschlag mit den mehrblock Zügen/Linien auch so sein. Es wäre allerdings aufwendiger die Linien zu erstellen. Angenommen dies ist die Hauptstrecke, möchte man dies nicht. Also baut man ein Ausweichstück.

o>>S3>>S2>>>>>>>>S1>o>>o>>>>S1>>>
v---------------------------^--^
>>>>>>>S1>>>>>>>>S1>^--^
>>>>>>>S2>>>>>>>>S1>>>^

Jetzt könnte man dem Güterzug auf der Hauptstrecke über das Ausweichstück schicken. Der ICE auf der Hauptstrecke könnte jetzt vor dem anderen ICE und dem Güterzug vorbei fahren.
Das funktioniert auch ohne Prioritäten. und mit den Linienbezognenen Blocklängen auch.

*mit erforderlich meine ich, dass ansonsten die Hauptstrecke (die mit der höheren Priorität) zum stocken kommen würde.
**das Wort Hauptsignal habe ich hier nicht realitätsgetreu genutzt. Es beschreibt einfach nur das letzte Signal vor dem Zusammentreffen der Gleise (da wo also in echt das Hauptsignal stehen würde, aber es funktioniert etwas anders)

@DarkMo Heutzutage können Grafikkarten einiges mehr als nur ein bischen mit Vektoren rechnen. Im großen und ganzen stimmt das aber. Die können einige wenige Dinge unglaublich schnell und GPGPU nutzt genau das aus. Es werden also Dinge die die GPU unglaublich schnell kann von einem auf der CPU laufenden (im Hauptspeicher arbeitenden) Steuerprogramm auf die GPU ausgelagert. Dies geschieht bei openCL z.B. so, dass ein so genannter openCL Kernel vom Steuerprogramm an die GPU gegeben wird. Dieser openCL Kernel erhält einen eigenen Speicherbereich im Spiecher der Grafikkarte, der vom Steuerprogramm initialsisert wird. Der openCL KErnel rechnet schnell seinen Teil durch und schreibt die Ergebnisse in diesen Berecih. Das Steuerprogramm holt sichd ann die Ergebnisse ab.

So weit zur theroetischen Funktionsweise. Es gibt neben openCL auch noch andere Schnittstellen wie CUDA, die aber wohl in diesem Fall nicht wirklich nützlich sind, da man damit alle Spieler an einen GPU Hersteller binden würde... openCL kennt btw. auch proprietäre Erweiterungen.

Ich habe mich vor ein paar Jahren mal mit der Sache beschäftigt. Das folgende könnte also nicht mehr up-to-date sein.

Ein Problem bei der Sache ist, dass es nicht damit getan ist ein Compiler flag zu setzen und schon geht es auf magische Weise auf die GPU. Das Verhalten muss man explizit coden und das ist auch deutlisch schwieriger als das selbe Programm einfach auf der CPU laufen zu lassen. Es ist also ein deutlicher Mehraufwand.
Es gibt allerdings einige Libs, die das ganze vereinfachen. Es bleibt ein Mehraufwand aber dieser hält sich dann wohl in Grenzen. Ich habe diese Libs aber selbst nie genutzt sondern nur ein wenig mit openCL aus Java heraus zu spielen (jocl). Es kann also sein, dass ich hier etwas daneben liege.

Das nächste Problem ist die kompatibilität.
Hierzu ein Zitat von tiker.net

Zitat

While OpenCL can natively talk to a large range of devices, that doesn't mean that your code will run optimally on all of them without any effort on your part. In fact, there's no guarantee it will even run at all, given that different CL devices have very different feature sets. If you stick to the OpenCL spec and avoid vendor-specific extensions, your code should be portable, if not tuned for speed. For now, it is safe to assume that you are facing efforts on the scale of a rewrite for your kernel code when switching devices for nontrivial codes. Fortunately though, the host-side code stays the same across devices.

Auch hier kann ich nicht sagen in wie weit die unterschiedlichen Frameworks dieses Problem lösen. Auch weiß ich nicht wie performant die Implementierungen sind.

Zu deiner Idee kann ich nicht viel sagen, da ich nicht genau weiß wie Meshes intern zu Pixeln weiterverarbeitet werden. Es sind zwar beides im Endeffekt nur Knoten und Kanten aber die Aktion ist eine gänzlich andere. Einmal interessieren uns die Flächen, da diese eben zu dem werden was man auf dem Bildschirm sieht (ggf. mit ner Textur drauf) und bei dem anderen interessieren uns erstmal die Kantenlängen als Weg zum Ziel aber vor allem der optimale Pfad auf dem man diesen Kanten folgen muss um zum ziel zu kommen. Außerdem interessiert an dieser Stelle die absolute Entfernung quasi garnicht, sondern die Reisedauer. Man müsste also erstmal ein Mesh so aufbauen, dass die Kantenlängen der Reisezeit entsprechen und ich bin mir ziemlich sicher, dass das im allgemeinen bei einem 3-d Mesh nicht möglich ist dieses Mesh aufzubauen.
Bsp: Knoten A,B,C
Kantengewichte: A-B 1, A-C 1, B-C 3
Aufgabe: wähle die Koordinaten der Knoten A,B,C so, dass die Kanten die Entsprechende Länge haben...
Du kannst also nicht jeden beliebigen Graphen in ein Mesh umwandeln, so lange die Kantengewichte etwas anderes als die Distanz zwischen den zum Knoten gehörenden Punkten sind.

Ob deine Idee also so funktioniert und ob das performant ist kann ich dir nicht sagen. Ich hoffe ich habe deine Idee zumindest richtig verstanden.
Auf jeden Fall kann man aber einen Algorithmus für openCL implementieren und die GPU den durchrechnen lassen. Das große Problem hierbei ist, dass die üblichen Algorithem für sowas keinen Blick auf Parallelität werfen. Man müsste also erstmal einen vernünftig parallelisierbaren Algorithmus finden, der diese Aufgabe erledigt. Wenn man ganz viel Glück hat gibt es dazu ein fertiges Graphen Framework, dass genau dies (hoffentlich performant) auf der GPU macht. Gibt es dieses Framework nicht, wird es wirklich viel Arbeit.

Es folgt irgendwo im Netz gelesenes Halbwissen (mit CUDA habe ich mich noch nie beschäftigt)
Ich weiß auch nicht ob für openCL der Modus der Grafikkarte gewechselt werden muss (ich habe mit openCL nochrum gespielt wenn gleichzeitig eine graisch aufwendiger Oberfläche angezeigt werden musste). Bei CUDA soll das zumindest mal so gewesen sein und die Zeit die der mode switch benötigt hat soll auch nicht ohne gewesen sin uns sich in Form von spürbaren lags geäußert haben. Also entweder man hat eine ungenutzte NVIDIA GPU im System oder man muss eben mit lags bei der Anzeige leben. Die Umschaltzeit soll aber bei neueren Karten deutlich niedriger liegen.

Erstmal danke für die Einblicke, das macht einiges deutlich klarer (besonders den Teil der Kommunikation). Wegen dem Graphenproblem an sich, ja das is natürlich tricky. Aber im schlimmsten falle muss ja irgendwer mal damit anfangen Die Frameworks sind ja auch nich *plopp* einfach da

Ok, wegen dem "gewichteten" Mesh da. Genau das Problem sah ich ja auch vorraus, daher diese zugegebenermaßen recht grob formulierte Idee mit den faktorisierten Vektoren. Also der Vektor an sich ist IMMER von Punkt zu Punkt, die Distanz bzw wie du richtiger sagtest Reisezeit ergibt sich dann aus der faktorisierten Distanz der Punkte. Also der Faktor wäre dann bspw die Geschwindigkeit eben.

Meshdaten werden an die GPU in - lass es mich nich allzu falsch ausdrücken, is bissl her bei mir >< - so öh Byteketten wie Arrays eben übertragen. Also eben alle Werte in nem bestimmten Format hintereinanderweg. Wo der nächste Vektor anfängt -> Offset. Nun kann man ja bspw einen 4D Vektor nehmen und den Skalierungs-Wert w einfach als diesen Faktor hernehmen, Skaliert ja quasi auch den Vektor Man bräuchte also eine Angabe, zu welchen Punkt/Vertex der Vektor gehört und den Vektor selber *hmm* Obwohl, is doch auch Käse oder? Für ein Mesh übergibt man auch die Vertices und... Ach ich glaub die Flächen noch! Genau, irgendwie so war das. Vertices alle hintereinander weg und diese werden für die Flächen per ID nur noch angesprochen und übergeben. Also bspw sagst du 0|0, 0|1 und 1|0 sind meine Vertices, dann speicherst eben 0,0,0,1,1,0 und ab dafür. Durch den Übertragungsmodus/Eigenschaft bla, weis nun die Graka "aha, das sollen 2D sein, also 0,0 gehört zusammen und sind die ersten -> ID0. Dann kommt 0,1 als Pärchen und das ist die ID1 usw. Und abschließend sagst du, welche Flächen aus den Vertices gebildet werden sollen. Hier soll halt das 3eck 0,1,2 gebildet werden. Ist halt diesmal int und 1D, bei Vertices isses eher float und 4D aber wurscht. So könnte man hier für die Flächen auch wieder die ID übergeben wie gewohnt aber wieder gepaart als 2D Vektor mit der Gewichtung/Geschwindigkeit. Das wäre ne Idee. Braucht man dann nur noch einen Algorythmus, der die Suche an sich übernimmt

Das wär doch mal was für meine Bachelor-Arbeit xD Wer schreibts mir?

Na dann habe ich auch schonmal ne Idee für die Bachelor Arbeit Ich habe gehört du schreibst die und ich schreibe meinen Namen drunter? Wobei... ich will ja garnicht Politiker werden. Dann muss ich das wohl doch selber machen

Hier ist dazu ein netter Überblick zu openCL. Ist aber wirklich nicht mehr als ein sehr grober Überblick.
http://ps.informatik.uni-siege…e-ws2011/wiersdoerfer.pdf
Such mal nach openGL Speichermodell, wenn du noch etwas mehr zur Kommunikation wissen möchtest.

Ja so in der Art klingt das machbar. Das müsste ich mir aber mal etwas genauer ansehen und vmich mal an einem kleinen Test Programm versuchen dann werden einem die Probleme meistens am besten klar.
Was die 4-D Vektoren da in der Grafikkarte zu suchen haben wenn man eh nur 3-D (bzw. auf dem Bildschirm sogar 2-D) haben möchte habe ich noch nie so wirklich verstanden. Wird wohl irgendwelche Berechnungen vereinfachen.

Edit: selbst erwischt! Lass mal wieder zurück zum eigentlichen Thema kommen
Kannst mir ja mal ne pn schicken oder ein Thema dafür auf machen.

Wir schagen doch den Devs grad vor, wie sie ihr Spiel zu bauen haben! Ist das etwa nichts? xD

Naja, also 3D im Hintergrund braucht es, damit durch die ganzen Transformationen ein perspektivisches 2D Bild generiert werden kann, und nicht die verhassten orthografischen Über die dritte Dimension wird eben diese "Tiefenverzerrung" gelöst (sofern die Frage ernst gemeint war ). Und 4D brauchts wohl bei Richtungen, so wie ich das verstanden habe. Als Beispiel ein Punkt mit der 4D-Darstellung 1|5|2|0. Bei Punkten ist w immer 0, wenn ich das richtig verstanden hab. Egal mit was du nun diesen Punkt multiplizierst, er bleibt IMMER an seiner Stelle, da w eben 0 ist. Anders bei Richtungen, hier wäre es 1|5|2|1. Eine Normale hätte also als Richtung auch eine 1. Richtungen können beliebig irgendwo an Punkte geheftet werden und zeigen dann halt irgendwohin. Skalierst du diese nun, so ändern sich auch die Werte. Mit 2 skaliert kommt dann eben 2|10|4|2 oder so raus. Glaub w wird mitskaliert? Bin mir grad unsicher ehrlich gesagt, würde es sinniger finden, wenn nicht Jedenfalls laut Theorie: Richtungen können unterschiedliche Längen haben. Nur eben die Richtung an sich darf sich nicht ändern. Ist hier gegeben. Die Länge hat sich zwar geändert, die Richtung jedoch nicht.

Wo ichs schon mit Normalen hatte: Ebene WEIL sie als Richtung skalierbar und damit nach einer Skalierung nicht mehr normiert sind, gibts öfters mal diesen "meh, wieso ist die Fläche jetzt plötzlich heller oder dunkler geworden" Effekt

@Freahk kommst du zufällig aus Siegen? Der link von der Uni Siegen bringt mich auf die Idee.