1. Foren
  2. Kommentare
  3. Games
  4. Alle Kommentare zum Artikel
  5. › Epic Games: Unreal Engine 4 und die…
  6. Thema

Interaktion mit Objekten in Spielen

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Re: Interaktion mit Objekten in Spielen

    Autor: phw 15.08.12 - 09:46

    Thaodan schrieb:
    --------------------------------------------------------------------------------
    > Oder zum Beispiel eine Mütze ich kann diese nicht einfach abnehmen oder
    > wenn diese zu einem Mantel gehört zurück schlagen. Oder die klassische
    > Aktion in fast jedem Spiel in dem ich einen Character kontrolliere und es
    > Items gibt, ich hebe Items auf und eigentlich hebe ich diese gar nicht auf
    > da die Items nach dem ich mich gebückt habe einfach in der Tasche sind. Was
    > ich sagen will ist das viele Spiele Grafiktechnisch immer realistischer
    > werden, aber hingegen in Sachen Interaktion immer noch Generation dahinter
    > sind wenn man es mit der Realität der Grafik vergleicht. Ich finde man
    > sollte lieber da was verbessern als an der Grafik.

    Ich stelle mir jetzt gerade vor, wie ich in Skyrim 10 Minuten beschäftigt bin, um meine Lederrüstung auszuziehen und in die Plattenrüstung zu schlüpfen. Und ich hätte meine Lederstiefel echt nicht mit einem Doppelknoten binden sollen, auch wenn das echt doof war als ich im Kampf gegen den Eistroll über meine Schnürsenkel gestolpert bin...

    Ich glaube Realismus in Spielen hat echt Grenzen.

  2. Re: Interaktion mit Objekten in Spielen

    Autor: teenriot 15.08.12 - 14:37

    burzum schrieb:
    --------------------------------------------------------------------------------
    > teenriot schrieb:
    > --------------------
    > > Der massive Einsatz von Partikel verrät auch im Artikel wo es hingeht.
    >
    > Nein.
    >
    > > In Zukunft wird es physikalische Welten geben die aus Atomen besteht.
    > Durch
    > > Implementation von einigen Grundkräften hat man bereits eine
    > vollständige
    >
    > Nur wird die Physik in Spielen auch heute nicht immer mit Masse und
    > Beschleunigung berechnet weil es zu aufwändig ist. Für ein Projektil das
    > von A nach B fliegt brauch ich keine realistische Ballistik in 99% der
    > Fälle, noch muß ein Fahrzeug einen korrekten Reibungswiderstand simulieren
    > auf dem jeweiligen Untergrund (was über Materialeigenschaften geht, nicht
    > über "Atome") außer es ist eine Rennsimulation.

    Ja klar kann man EINZELNE physikalische Effekte performanter hintricksen mit heutigen Methoden, aber was ist denn das für ein Argument? Ich kann auch mit 'nem Motorroller im Regen billiger nach Rom fahren, als mit einem Auto,
    Sachen wie Kleidung, Mimik, Haare kriegt man aber nicht so hingefaked wie du es beschreibst. Erzähl mir nicht das will keiner oder das wäre nicht notwendig.
    Man will es, man versucht es, man kriegt es nicht hin.

    >
    > > Physikengine in der sich selbst die komplexesten Objekte vollkommen
    > korrekt
    > > verhalten, ob flüssig, fest oder gasförmig. In Zukunft wird die
    > > Graphikengine auf die Physik/Welt-Engine aufgesetzt werden und nicht
    > > umgekehrt. In Zukunft wird es nur noch Raytracing/Raycasting geben weil
    > es
    > > nur mit diesen Techniken möglich ist mehr oder weniger unabhängig von
    > der
    > > Gesamtzahl der Atome ein Abbild zu erstellen.
    >
    > Definiere Grafikengine? Meinst Du den Renderer? Dann stimmt die Aussage.
    > Falls nein, liegst du falsch. Ein Part der Engine muß ja wissen wo was ist
    > und wie es zu zeichnen ist wärend die Physikengine andere Informationen
    > braucht, eigentlich reicht der nur zu wissen das dort X und da Y ist, wie
    > das Objekt aussieht ist der Physikengine total egal und umgedreht auch.

    Ich meine Renderer.
    Auch für die Physik braucht es nur einen Vektor. Für die Eigenschaft braucht es eine Zahl (Klasse).
    Ansonsten kapiere ich nicht was du mir gerade sagen willst.
    Willst du mir erzählen das der Renderer wesentlich mehr Voxel "anfassen" muss als im Sichtfeld vorhanden?
    Es ist Quatsch wenn du sagst das der Renderer nur die Position der Atome kennen muss. Es muss auch die Klasse kennen. Somit braucht der Renderer die gleichen Daten wie die Physikengine.

    > Du hast entweder absolut keine Ahnung oder ein *RIESEN* Mißverständnis
    > irgendwoher wie diese Techniken angeblich funktionieren sollen.

    Wenn du meinst. Ausgedrückt hast du bisher aber nicht.

    >
    > > Es hakt, nur den Rechnern und da in erster Linie am RAM. Kleine
    > > physikalische korrekte Voxelwelten gibt es bereits schon, aber um einen
    > > Kubikkilometer mit 1cm großen Atome im Speicher ohne Kompression
    > abzubilden
    > > braucht es 1mio Gigabyte bei einem byte pro Voxel.
    >
    > Das wird *nie* in einer brauchbaren Größenordnung machbar sein. Und Deine
    > niedliche Theory das man "nur" die Grundkräfte braucht (die auch noch in
    > Wechselwirkung stehen) ist schon mal hinfällig, da auf atomarer Ebene
    > andere Gesetzmäßigkeiten gelten als in unserem Makrokosmos.

    Hast du Probleme mit bildlicher Sprache?
    Genausowenig wie ich mit Atome 10^-10m große Materiehaufen meine, meine ich mit Grundkräfte nicht die realen physikalischen Grundkräfte.
    Du hast wohl " absolut keine Ahnung oder ein *RIESEN* Mißverständnis", denn das dem so ist, ist offensichtlich aus meinen bisherigen ausführungen. Allein das Wort Atom ( Unteilbar) sollte dir den Wink geben das man nicht Quantenmechanik umsetzen will.
    Im einfachsten Fall braucht es nur einer Grundkraft, einer Bindungskraft Zwischen den Atomen. Alles andere is normale newtonsche Physik.

    > Ich hätte gern eine Quelle für eine korrekt arbeitende Voxelengine in der
    > Jeder Voxel eine Masse hat und sich je nach Material auch anders verhält
    > was Viskosität und Reibungswiderstand angeht. Und bei dem gibt es gleich
    > einen Sack voller Dinge zu beachten -> de.wikipedia.org

    Ja toll. Zeig du mir eine korrekt arbeitende Polygon-Engine die das kann.
    Kannste nicht? Ja dann gibt es wohl auch keine funktionierenden Polygon-Engines.
    Was ist denn das für eine Art der Argumentation?
    "Viskosität", du machst dich lächerlich. Ich rede nicht von einer wissenschaftlichen Gottessimulation die in einem Arbeitsschritt von heute auf morgen erstellt werden kann.

    Aber wenn du mal was sehen willst: http://www.youtube.com/watch?v=J9HaT23b-xc
    Anmerkung: Niemand hat gesagt das Atome uniform oder symmetrisch sein müssen.

    > Außerdem braucht es immer mehr Informationen pro Atom. Selbst wenn man also
    > mit einem Atom den Zustand und die Position eines Atoms in der Spielwelt
    > festlegen könnte (was nicht geht) würde man für jedes Atom im Spiel eines
    > auf dem Datenträger brauchen...

    Und jedes Polygon muss auch irgendwo gespeichert werden. Großartige Erkenntnis, aber worauf willst du hinaus?

    >
    > > Mit Kompression ist das trotzdem bereits heute handhabbar, aber dann
    > hakt
    > > es an der CPU und dem "teuren" Zugriff auf einzelne Elemente wenn es um
    > die
    > > Physik geht.
    >
    > Ok, dann her mit den Beispielen? Ich vermute eher Du meinst Datenwolken,
    > ich komme gerade nicht auf den genauen Namen, die im Prinzip eine Gruppe
    > von Voxeln beschreiben um die Verarbeitung schneller zu machen. Mit
    > Kompression hat das aber nichts zu tun.

    Man kann Voxeldaten (zwar nicht beliebige) millionenfach komprimieren, durch Instanzierung.

  3. Re: Unsinn

    Autor: teenriot 15.08.12 - 14:46

    JanZmus schrieb:
    --------------------------------------------------------------------------------
    > teenriot schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Es geht darum
    > > das wir alle Algorithmen haben um physikalisch korrekte Welten zu
    > > erschaffen, (...). Mit
    > > Atomphysik braucht es keine Haar-Simulation, Kleidungssymulation,
    > > Mimik-Simulation usw. Es braucht nur Atomgenaue Bindungskräfte und etwas
    > > newtonsche Physik um Gas über Wasser durch Wellenbewegung in Bewegung zu
    > > setzen, um Blätter individuell vom Baum Segeln zu lassen, um Beton zu
    > > zersprengen, um Glas zum splittern zu bringen, um Reifenspuren im Sand
    > zu
    > > erzeugen, um Dünen wandern zu lassen ....
    >
    > Das ist grober Unsinn, denn du gehst du von nur einer "Atomart" aus, in der
    > Wirklichkeit entstehen die unterschiedlichen "physikalischen Eigenschaften"
    > ja aber aus unterschiedlichen Atomen, Molekülen und Verbindungen. Deine
    > Spielwelt würde sich verhalten wie eine Welt, die z.B. NUR aus
    > Kohlenstoffatomen besteht, das wird glaube ich nichts mit deiner "Haar-"
    > und "Mimiksimulation".

    Grober Unsinn ist es davon auszugehen, das ich von einer Atomart ausgehe.
    Natürlich brauche man physikalische Entitäten unterschiedlichen Typs. Aber mit 4, 5 Klassen kann bereits komplexe Sachen machen. Man muss kein Periodensystem erfinden und Moleküle braucht man überhaupt nicht. Es bedarf auch keiner Wechselwirkung zwischen den Atomtypen, abgesehen von newtonscher Physik.

    >
    > > Komplexitaetsgrenzen gibt es nur mit der jetzigen aufgesetzten Physik,
    > bei
    > > dem jeder Effekt komplexer zu implementieren ist, um kompatibel zu den
    > > bereits bestehenden zu bleiben. Atomphysik ist lächerlich simpel im
    > > Vergleich dazu und muss nur einmal implementiert werden um ALLE Effekte
    > auf
    > > einen Schlag zu haben.
    >
    > Noch zwei Beispiele, warum dein Ansatz Unsinn ist:
    >
    > 1) Ich muss durch einen Gang um in dem Spiel weiter zu kommen. Durch die
    > realistische Physik habe ich diesen aber zum Einsturz gebracht... total
    > unsinnig für ein Spiel.
    >
    > 2) Ich muss z.B. eine Truhe finden und irgendwo abliefern, um in dem Spiel
    > weiterzukommen. Durch die realistische Physik habe ich diese aber aus
    > versehen in 20 Teile zertrümmert... total unsinnig für ein Spiel.

    Oh ja, jetzt hast du mich. *Kopfschüttel*
    Hätte ich das mal zuerst gelesen, dann hätte ich keine Zeit mit diesem Beitrag verschwendet.

  4. Re: Interaktion mit Objekten in Spielen

    Autor: teenriot 15.08.12 - 16:12

    GiveUsMcNeal! schrieb:
    --------------------------------------------------------------------------------
    > teenriot schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Demos die jetzt bereits funktionieren. Also hör auf mit deinen
    > > grundsätzlichen Einwänden und, wie bereits woanders erwähnt, wende dich
    > dem
    > > Thema der ZUKUNFT zu. Dabei darfst du dann gerne mit 1000facher
    > > CPU-Leistung und 100000fachen großem RAM ausgehen, wenn dir das
    > > Vorstellungsvermögen fehlt wie man mittels Instanzierung, Kompression,
    > > selektiver Physik, hohlen Objekten, Octrees und vielem mehr, in
    > bereits,
    > > sagen wir mal 5 Jahren, praxis- und kommerztaugliche Produkte erschaffen
    > > kann.
    >
    > mit instanziierung, selektiver physik, hohlen objekten geht man weg vom
    > generellen model zu spezialfaellen. in deinem ersten post sagst du noch die
    > zukunft ist weg von spezialfaellen und alles durch atome, elementarphysik
    > und raytracing ersetzen. und jetzt geht das aufeinmal wieder in richtung
    > fakes.

    Ok. Ich habe mehrere Aussagen vermischt. Ich rede über 2 Zeitpunkte.

    1) idealisierte Ferne Zukunft (25-100 Jahre)
    RAM & CPU ignoriert, sage ich das wir die Algorithmen haben um eine Zweitwelt(Echtwelt trifft es nicht) auf Brute-Force Art im Speicher abzubilden und zu verarbeiten. Dafür muss prinzipiell nur das Atom-Verhalten implementieren und das ist einfacher & realistischer als der heutige Mix von aufgesetzten & sehr beschränkten Effekten.

    2) Nähere Zukunft (3-6 Jahre)
    Ram&CPU nicht ignoriert kann man durch Optimierungen taugliche Produkte schaffen.

    Hohle Objekte sind kein Fake, denn die Algorithmen bleiben unberührt.

    > besonders bei deinem vorschlag mit bindekraefte zwischen atomen
    > funktioniert dass dann auch nicht mehr ohne wirklich alle atome anzufassen,
    > sprich: nix mit selektiver physik.

    Selektive Physik muss auch kein Fake sein, wenn ich z.B. Fels-Atome mit einer Masse belege die diese quasi unbewegbar macht. Ich erstelle also ein Level dessen Boden aus Fels besteht und packe darauf 30 cm Sand. So habe ich elegant dafür gesorgt das der größte Teil der Welt, starr bleibt und somit nicht berücksichtigt werden muss. Denn wenn man die Kräfte berechnet muss man nur die Atome berücksichtigen deren Position sich seit dem letzten Frame verändert hat. Diese mögen dann andere Atome "aktivieren".

    Instanzen wären ein echter Fake. Ja gut, dann gibt es übermorgen eben ein physikalisches Minecraft mit einer milion Bäumen die aber Instanzen sind und somit nicht berücksichtigt werden. Wen juckt das? Die Leute sind selbst heute ohne allem verrückt nach Minecraft.

    Es geht nicht darum die echte Welt 1:1 zu kopieren.
    Es geht darum überhaupt erstmal eine Welt zu schaffen

    > > Das ist überhaupt nicht notwendig. Eine Echtwelt-Simulation muss nicht
    > wie
    > > eine Echtwelt funktionieren, sie muss sich nur so verhalten. Wenn man
    > einen
    > > diskreten Raum verwendet lösen sich viele Probleme von selbst. Mag sein
    > das
    > > ein Objekt dann z.B. nicht absolut korrekt rotiert, aber das ist
    > > irrelevant, weil es nicht um wissenschaftliche Simulationen geht.
    > Deswegen
    > > braucht es diesen "Kram" nicht:
    >
    > und wie das notwendig ist. wie willst du denn deine fallenden blaetter
    > simulieren, wasser, sand, und sonstige umgebungseffekte, die die umwelt
    > veraendern? da muss alles mit allem interagieren was wieder den neuaufbau
    > der datenstruktur erfordert mit O(n log n) im worst case.
    > ist auch klar dass du zu diesem komplexitaetsargument nichts zu sagen
    > hast.
    > und ein 'diskreter Raum' erschafft auch viele probleme da die welt
    > kontinuierlich funktioniert (auf der skala).

    Ich habe mich zu dem "Komplexitaetsargument" geäußert und zwar mehrfach und tue es jetzt wieder.
    Ich sage das in einem diskreten Raum keine aufwendigen "Stabilisierungstechniken" notwendig sind.
    Es muss nicht alles mit allem interagieren. Alles bewegte muss mit der direkten Nachbarschaft interagieren. Klar wenn du aus dem Fenster guckst bewegt sich scheinbar alles. Man kann aber eine Virtuelle Realität kreieren die zu 99,9% starr ist und trotzdem belebt wirkt.
    Warum ein Neuaufbau von Daten notwendig sein soll erschließt sich mir nicht, wenn es darum geht die Position von Atomen zu verändern.

    > > Ich habe nirgends gesagt das es einfach ist.
    > Stimmt, du hast nur gesagt das es simpel ist und man alle Effekte auf einen
    > Schlag bekommt. Wie dumm von mir da 'einfach' statt 'simpel' zu schreiben
    > :-)

    Jetzt sind wir also bei Wortklauberei angelangt.
    Man bekommt alle Effekte auf einen Schlag wenn man das Atomverhalten entsprechend implementiert. Das ist vom programmtechnischen her keine TRIVIALE Aufgabe, aber grundsätzlich EIN!!!!! EINFACH GESTRICKTERER Algorithmus, als die heutige Kombination verschiedener Algorithmen die das Verhalten für eine Gruppe von Atomen (nichts anderes sind letztlich auch Polygone, bzw deren geometrische Basis) jeweils für einen speziellen Effekt auf meist schlechte unrealistische Art beschreiben.

    > > Was ich aber sage das man sich etwas Besserem, einfacherem annähern
    > kann.
    > > Pong -> Crisis3
    > Crysis3 = ansammlung von hacks um moeglichst viel aus der HW rauszuholen.
    > Und in welchem Bezug steht jetzt diese polygonbasierte Engine mit der
    > Schwierigkeit von einer stabilen Simulation?

    Und in welchem Bezug steht deine Frage zu deinem Verständnisproblem?

    > > Ganz nette Demo die beweist, das es das was du grundsätzlich
    > ausschließt,
    > > gibt.
    > Nein eben nicht, sie zeigt minimal aenderungen des terrains ausgeloest
    > durch 5 grobe objekte. Keinerlei interaktion zwischen sandpartikeln
    > erkennbar. und die sandpartikel verschwinden auch nur.

    Sieh es als Machbarkeitsstudie von zukünftigen Algorithmen.
    Deine Art die Innovation und Leistung andere schlecht zu machen ist widerlich.
    Du benimmst dich wie ein Zeitreisender der ins Jahr 1900 zurückreist und die Automobilpioniere zutextet.

    > ich habe auf deren
    > homepage nichts gefunden, was darauf hindeuten koennte dass die sowas
    > koennten wie sandstuerme, umfallende baume oder pflanzen, die sich im wind
    > wiegen

    Hat das denn irgendjemand behauptet?
    Kannst du mal bitte aufhören hier alle Nase lang, als Argumentationsersatz, einen auf
    "Wenn es nicht aussieht wie Schloß Schwanstein, dann ist es kein Haus" zu machen?

    >. im prinzip dasselbe wie unlimited detail (statische welt), scheint
    > allerdings etwas besser zu sein und erlaubt einfache aenderungen des
    > terrains, allerdings nur loeschen.

    Hast du den immer noch nicht kapiert das UD eine Grafigengine und keine Physikengine ist? Es wurde dir ja nur mehrmals gesagt.

    >
    > > Du hattest behauptet das Unlimeted Details behauptet eine Lösung für
    > alles
    > > zu sein.
    > > Du hattest behauptet das man auf Unlimeted Details hereinfallen würde.
    > > Die gibst also zu Blödsinn erzählt zu haben?
    > Euclidion hat behauptet "we have found a way to give computer graphics
    > unlimited power" und aehnliche beweisbar falsche Aussagen.

    Wo steht da was von "eine Lösung für alles"? Ich lese nur was von Graphik.
    Entweder bist du doch kein UD-Experte oder du hast gerade Rufschädigung durch das verfäschendes, selektives Zitieren betrieben. UD sagt explizit an Menschen mit Sachkenntnis gerichtet, das es natürlich nicht unendliche Details gibt. So wird in der einen Demo die Maßeinheit 1/64mm in den Raum geworfen. Es wird lediglich an Laien gerichtet gesagt das das Ergebnis praktisch unendliche Details sind, was de facto stimmt wenn die Atome unterhalb der Wahrnehmungsgröße liegen. Außerdem gehe ich davon aus das ihr Algorithmus tatsächlich unendliche Details verarbeiten kann und die Grenzen eher durch den RAM gesetzt sind.

    > > Du erzählst mir irgendwas über (heutige) Grafikkarten als Argument für
    > > deine Behauptung das Atom-Engines prinzipiell am stärksten durch die CPU
    > > beschränkt sind. Das ist nicht wirklich sinnig oder?
    > Dir ist anscheinend nicht klar dass eine heutige Grafikkarte einfach nur
    > nen riesen Array von Prozessoren ist mit ein paar spezialfunktionen. Aber
    > definitv nicht auf Polygone beschraenkt.

    Dennoch ist das Kaufverhalten von DirektX und Open-GL Hardware, das du ursprünglich angeführt hast, kein Argument für irgendwas betreffs Voxel.

    > Zurueck zum Thema: Selbst mit unendlich viel Speicher kriegst du immer noch
    > keine "Atom"-engine hin, bei der Partikel beliebig interagieren koennen
    > ohne die Partikel in zu laden, deren interaktionspartner zu ermitteln, und
    > die gesamte datenstruktur zu aktualiseren. Deshalb ist Speicher kein
    > Argument, eher Speicherbandbreite und synchronisation.

    Das hatten wir oben schon. Du liegst falsch.
    Um die Interaktionspartner zu ermitteln muss man nur ein paar dutzend/hundert Atome anfassen mittels Octrees.

    >
    >
    > > Immer wenn die nix einfällt wirfst du 'Spezialfall' in den Raum.
    > > Wenn ich die Voxel ausschließlich als Würfel ohne Reflexion & Schatten
    > > mittels Raytracing rendere, ist und bleibt es Raytracing und dann komme
    > ich
    > > unterhalb linearer Zeitkomplexität. Wenn ich dazu einen diskreten Raum
    > und
    > > Octrees verwende dann werde ich sogar weitaus besser als log(n) und kann
    > > mir Spielchen wie Schatten und Reflexion erlauben.
    >
    > Nur weil du wenig von der Materie verstehst heisst das noch lange nicht,
    > dass O(log n) Raytracing kein Spezialfall ist.

    Hör doch auf. So lange du die Weltformel nicht hast ist ALLES ein Spezialfall.
    Das ist das dümmste und damit beste IT-Totschlagargument das ich je gehört habe.
    Polygonengines mit Gleitkommaungenauigkeiten? => Speziallfall
    Polygonengines mit Far und Near-Clipping? => Speziallfall
    Polygonengines mit Bumpmaps? => Speziallfall
    ...

    > Einfaches Gegenbeispiel
    > waere hier ein Wald mit N Bauemen auf einer quadratischen Flaeche
    > platziert.Viele Strahlen schiessen komplett durch ohne einen Baum erwischt
    > zu haben und ein Teil ist ganz nah an O( sqrt(N) ) Bauemen. Die muessen
    > jetzt alle aus der Hierarchie ausgepackt werden. Bedeutet, O( sqrt(N) ) >
    > O( log N) Aufwand und damit nicht logarithmisch. Man kann auch Faelle mit
    > O(N) konstruieren z.B. eine Allee.

    Schlicht blödsinn.
    Mit Octrees muss ich nur den allerkleinsten Teil auspacken.
    Und auspacken muss man nur wenn man komprimiert.

    > Raytracing hat ausserdem den Nachteil dass man soviele Strahlen verschicken
    > muss um Rauschen zu vermeiden, gerade bei Reflektionen.
    Das ist kein Problem von Raytracing.
    Das ist ein Problem der CPU.
    Es ist dein Problem das du nur hochqualitatives Raytracing mit allen möglichen Lichteffekten als Raytracing anerkennst.

    > Beim Forwardmapping
    > hat man sowas nicht. Und wie man an der neuen Unrealengine sieht kriegt man
    > auch sowas wie glossy reflexions.

    Was ein Texur-Algorithmus so alles kann.
    Forwardmapping löst das grundsätzliche Problem von Raster-Polygon-Engines das wesentlich mehr Pixel verarbeitet werden als sichtbar sind?
    Du kannst es dreh und wenden wie du willst ab einem bestimmten Verhältnis von Daten pro Pixel/Sichtlinie ist raytracing prinzipbedingt performanter als Polygonengines. Mag sein das das erst in 50 Jahren relevant ist.

    > > > Und je paralleler das wird, desto schwieriger
    > > > wird es die Leistung auch auszunutzen. Hier hat Rasterisierung weil
    > das
    > > > trivial zu parallelisieren ist.
    > >
    > > Du hängst im Heute, im offtopic...
    > > Bei den heutigen Methoden ist nur der kleinste Teil der Rasterisierung
    > > wirklich sichtbar. Deswegen allein ist diese Technik keine gute Wahl
    > wenn
    > > man die Datenmengen mehr und mehr steigert. Zukunftsträchtige
    > > Render-Technologien müssen die Renderzeit möglichst unabhängig von der
    > > Größe der zu verarbeitenden Daten machen. Das geht nur dadurch das man
    > nur
    > > das berücksichtigt was man wirklich sieht. Das ist mit Polygon-Engines
    > > ausgeschlossen, geht aber mit Raytracing.
    > Ist mit beiden moeglich (*), aber du brauchst ein level-of-detail konzept.
    > Pures Raytracing killt dich immer wieder durch die paar Strahlen die
    > geradeso durchhuschen und dabei ordentlich im speicher rumwuehlen.

    Du hast immer nur herkömmliches komplexes Raytracing im Kopf.
    Wir reden hier aber über Raytracing mit maximal 2/3 Primitiven in einem DISKRETEN Raum. Dann huscht da eben was durch wenn man nicht genug CPU hat. Das Argument lässt die Sache aber prinzipiell genauso unberührt wie das Äquivalent Antialiasing Polygonengines prinzipiell unberührt lassen.
    Was genau meinst du mit im "im speicher rumwuehlen"?

    > Und, um nochmal auf den Hierarchieupdate zurueckzukommen: Sobald du eine
    > dynamische Welt hast, musst du deine Datenstruktur pro Frame aktualisieren,
    > was du immer wieder zu vergessen scheinst.

    Nee das vergesse ich nicht. Davon rede ich seit Anfang an. Aber ich bin stolz das du das endlich kapiert hast. Das Rendering ist Nebensache.
    Man rendert die physikalischen Welt und versucht nicht wie heute eher eine graphische Welt mehr schlecht als recht physikalisch zu verarbeiten.
    Die Qualität der physikalischen Welt steht im Vordergrund und nicht ob man mit Reflexionen rendert oder nicht.
    Man kann die Welt nur insoweit dynamisch halten wie es die CPU zulässt das ist klar.
    Wenn man momentan nur ein paar tausend Atome dynamisch verarbeiten kann, dann muss dafür sorgen das sich nicht mehr bewegen. Wenn man mit ein paar tausend Atomen nichts anfangen kann sondern mindestens 100000 braucht dann muss eben 99% starr sein. Dann ist eben 99% der Welt Fels. Ja Und?
    Die Rechner werden besser die Welten werden besser.
    Das ist als kein gültiges Argument gegen den Algorithmus an sich.

    > (*) moeglich im sinne von logaritmischem Aufwand.
    Ohne Far-Clipping?
    Ohne "durchhuschen"?
    Wie genau soll das gehen?
    Werden dann nur noch die Daten pro Sichtlinie verarbeitet die relevant sind oder bist du dir mit log N doch nicht so sicher?

  5. Re: Interaktion mit Objekten in Spielen

    Autor: irata 15.08.12 - 18:52

    teenriot schrieb:
    --------------------------------------------------------------------------------
    > Heightmaps sind ein Algorithmus um Voxel zu speichern

    Heightmaps sind zweidimensional und Voxel dreidimensional.
    Aus den Heightmaps werden unterschiedliche Höhen generiert, Überhänge, Höhlen und beliebige Objekte sind damit nicht möglich - es sei denn, man verwendet mehrere Heightmaps, was aber immer noch sehr viele Einschränkungen hat.
    http://en.wikipedia.org/wiki/Heightmap

  6. Re: Interaktion mit Objekten in Spielen

    Autor: teenriot 15.08.12 - 19:29

    irata schrieb:
    --------------------------------------------------------------------------------
    > teenriot schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Heightmaps sind ein Algorithmus um Voxel zu speichern
    >
    > Heightmaps sind zweidimensional und Voxel dreidimensional.
    > Aus den Heightmaps werden unterschiedliche Höhen generiert, Überhänge,
    > Höhlen und beliebige Objekte sind damit nicht möglich - es sei denn, man
    > verwendet mehrere Heightmaps, was aber immer noch sehr viele
    > Einschränkungen hat.
    > en.wikipedia.org

    Heighmaps in den raycasting-engines speichern nichts anderes als die Positionen von Voxeln, mit der Farbe als y-Wert. Die raycasting-engines testen nicht die Kollision des Sehstrahls mit der Heightmap an sich, sondern mit den Voxeln die durch die Heightmap definiert werden.

    http://de.wikipedia.org/wiki/Heightmap:
    "Höhenfelder sind zweidimensionale skalare Felder, die ein Höhenrelief beschreiben. Jedem Ort ist hier also ein Wert zugeordnet, der eine Position in der dritten räumlichen Dimension angibt, eine Höhe."

    Diese "Orte" sind die Positionen der Voxel, welche eine Kantenlänge von einem Pixel haben.



    1 mal bearbeitet, zuletzt am 15.08.12 19:31 durch teenriot.

  7. Re: Interaktion mit Objekten in Spielen

    Autor: irata 15.08.12 - 19:41

    GiveUsMcNeal! schrieb:
    --------------------------------------------------------------------------------
    > die erwecken den eindruck dass das ne gute gameengine sein koennte und
    > besser ist als alles, was es bisher so gab.

    Bezüglich z.B. LOD finde ich das schon hochinteressant, was die da machen.
    Und wenn die Algorithmen wirklich grundlegend verschieden von herkömmlichen Methoden sind, wie behauptet, hat das sicher noch enormes Potential.
    Wobei sich Euclideon derzeit offenbar mehr auf geografische Visualisierung konzentriert.

    > und sie behaupten sie koennten 'unlimited' detail. ich finde schon dass das etwas von betrug hat :-)

    Und früher gab es mal "unlimited sound-channels", "unlimited sprites", "unlimited polygons". War im Kontext betrachtet sogar korrekt, wenn man weiß was "unlimited" bedeutet.
    Auch Crytek wirbt mit "Unlimited Particle FX Lighting", viele Internet Provider bieten "unlimited downloads" an, bei Onlineshops kann man "unlimited products" eingeben usw.
    Witzig ist auch, wenn ein Mobiltelefon-Display bei einer Auflösung von 640x480 Pixel 16 Millionen Farben "gleichzeitig" darstellen kann.
    Ist das auch "Betrug", auf den die Leute "reinfallen"?
    ;-)

  8. Re: Interaktion mit Objekten in Spielen

    Autor: irata 15.08.12 - 19:47

    teenriot schrieb:
    --------------------------------------------------------------------------------
    > Diese "Orte" sind die Positionen der Voxel, welche eine Kantenlänge von
    > einem Pixel haben.

    Trotzdem kann man mit Voxel beliebige Objekte darstellen, mit Heightmaps eben nicht.
    Manche bezeichnen es als "voxel columns", aber der Begriff Voxel ist hier sehr irreführend.
    Ich würde auch nicht den Begriff Pixel verwenden, wenn man nur ganze Zeilen darstellen kann.

  9. Re: Interaktion mit Objekten in Spielen

    Autor: teenriot 15.08.12 - 20:38

    irata schrieb:
    --------------------------------------------------------------------------------
    > teenriot schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Diese "Orte" sind die Positionen der Voxel, welche eine Kantenlänge von
    > > einem Pixel haben.
    >
    > Trotzdem kann man mit Voxel beliebige Objekte darstellen, mit Heightmaps
    > eben nicht.

    Man versucht ja auch nicht die Voxel für beliebige Objekte mittels Heightmaps abzuspeichern.

    > Manche bezeichnen es als "voxel columns", aber der Begriff Voxel ist hier
    > sehr irreführend.
    'voxel columns' ist irreführend weil dieser Begriff nämlich den Abtastalgorithmus und den Datenhaltungsalgorithmus sinnfrei verbindet und den Eindruck erweckt als ginge es nur um Datenhaltung.

    > Ich würde auch nicht den Begriff Pixel verwenden, wenn man nur ganze Zeilen
    > darstellen kann.

    ??? Wer sagt das man nur ganze Zeilen darstellen kann?
    Es war damals EINE sehr performante Optimierung Rechenzeit durch bestimmte Voraussetzungen zu sparen, dadurch das die Sehstrahlen nicht vollständig abgetastet werden mussten.
    Diese Voraussetzungen/Einschränkungen sind aber nicht zwingend notwendig.

  10. Re: Interaktion mit Objekten in Spielen

    Autor: GiveUsMcNeal! 15.08.12 - 23:20

    teenriot schrieb:
    --------------------------------------------------------------------------------
    > Ich sage das in einem diskreten Raum keine aufwendigen
    > "Stabilisierungstechniken" notwendig sind.

    Wunschdenken.

    > Es muss nicht alles mit allem interagieren. Alles bewegte muss mit der
    > direkten Nachbarschaft interagieren. Klar wenn du aus dem Fenster guckst
    > bewegt sich scheinbar alles. Man kann aber eine Virtuelle Realität kreieren
    > die zu 99,9% starr ist und trotzdem belebt wirkt.
    > Warum ein Neuaufbau von Daten notwendig sein soll erschließt sich mir
    > nicht, wenn es darum geht die Position von Atomen zu verändern.

    Klar erschliesst sich dir das nicht. Du offenbarst mehr und mehr dass du nur mit Halbwissen argumentierst und scheinst viele Grundkonzepte nicht zu kennen. Z.B. warum eine Veraenderung der Position eines Atoms den Octree veraendert.

    > > Einfaches Gegenbeispiel
    > > waere hier ein Wald mit N Bauemen auf einer quadratischen Flaeche
    > > platziert.Viele Strahlen schiessen komplett durch ohne einen Baum
    > erwischt
    > > zu haben und ein Teil ist ganz nah an O( sqrt(N) ) Bauemen. Die muessen
    > > jetzt alle aus der Hierarchie ausgepackt werden. Bedeutet, O( sqrt(N) )
    > >
    > > O( log N) Aufwand und damit nicht logarithmisch. Man kann auch Faelle
    > mit
    > > O(N) konstruieren z.B. eine Allee.
    >
    > Schlicht blödsinn.
    > Mit Octrees muss ich nur den allerkleinsten Teil auspacken.
    > Und auspacken muss man nur wenn man komprimiert.
    >

    Fuer Nicht-Grafiker ist das wohl zu kompliziert. Stell dir einen Strahl vor, der ganz knapp an einer Reihe von Grashalmen(sagen wir M) vorbeischiesst und nur den letzten Halm trifft. Du musst bei jedem einzelnen Grashalm bis zur eigentlichen Geometrie runtersteigen um zu erkennen, dass der Strahl den Halm nicht schneidet. Und dieses runtersteigen und schnitttests durchfuehren kostet Aufwand, und das fuer ALLE M grashalme.
    Dass du dieses Gegenbeispiel mit dem Octree-zaubert-das-weg Argument wegwischen willst zeigt wieder dass du nur mit Halbwissen argumentierst.

    > > Pures Raytracing killt dich immer wieder durch die paar Strahlen die
    > > geradeso durchhuschen und dabei ordentlich im speicher rumwuehlen.
    >
    > Du hast immer nur herkömmliches komplexes Raytracing im Kopf.
    > Wir reden hier aber über Raytracing mit maximal 2/3 Primitiven in einem
    > DISKRETEN Raum. Dann huscht da eben was durch wenn man nicht genug CPU hat.
    Schon wieder wird komplexitaet durch den 'diskreten' Raum weggezaubert. Ohne LOD nuetzt dir die diskretisierung nix. Auch in sparse voxel repraesentation kriegt man keinen logarithmischen Aufwand hin ohne LOD zu verwenden.

    > Was genau meinst du mit im "im speicher rumwuehlen"?
    Speicher an zufaelliger Addresse auslesen -> kein caching moeglich, killt die performance.

    > Wenn man momentan nur ein paar tausend Atome dynamisch verarbeiten kann,
    > dann muss dafür sorgen das sich nicht mehr bewegen. Wenn man mit ein paar
    > tausend Atomen nichts anfangen kann sondern mindestens 100000 braucht dann
    > muss eben 99% starr sein. Dann ist eben 99% der Welt Fels. Ja Und?
    Mit andern Worten: statische Welt die eigentlich keine Physik benoetigt weil sich ja eh nix bewegt.

    > > (*) moeglich im sinne von logaritmischem Aufwand.
    > Ohne Far-Clipping?
    Ja, wobei das nix damit zu tun hat. Ich kann meine Szene auch innerhalb der Clippingregionen detailierter machen.
    > Ohne "durchhuschen"?
    Ja
    > Wie genau soll das gehen?
    Indem man approximiert. Primitive, die weiter weg sind werden durch weniger polygone dargestellt. Man kann dann auch auf imposter gehen oder andere LOD repraesentation, z.B. einfach zufaellig punkte sampeln.
    > Werden dann nur noch die Daten pro Sichtlinie verarbeitet die relevant sind
    > oder bist du dir mit log N doch nicht so sicher?
    Ist halt der prinzipielle Unterschied von Forwardmapping zu Backwardmapping. Beim Forwardmapping projeziert man alle Elemente ins Bild, und LOD fasst dann Elemente zusammen damit man nur noch log n elemente braucht.

    Ich glaube dir sind die subtilen Unterschiede zwischen verschiedenen Techniken nicht klar und kennst die grundlegenden Grenzen nicht, z.b. das mehr RAM die Probleme nicht loest. Ich hab auch keine Lust da jetzt jeden einzelnen Punkt weiter einzugehen weil du dir nichtmal die muehe machst den raytracing worst case zu verstehen. Dir fehlt schlicht und einfach Fachwissen um so eine Diskussion fuehren zu koennen.

  11. Re: Interaktion mit Objekten in Spielen

    Autor: Hotohori 15.08.12 - 23:27

    Nur bei gewissen Sorten von Spielern. ^^

  12. Re: Interaktion mit Objekten in Spielen

    Autor: teenriot 16.08.12 - 02:20

    GiveUsMcNeal! schrieb:
    --------------------------------------------------------------------------------
    > teenriot schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ich sage das in einem diskreten Raum keine aufwendigen
    > > "Stabilisierungstechniken" notwendig sind.
    >
    > Wunschdenken.

    Ja komm, lass dich aus.
    Was muss stabilisiert werden, abgesehen davon das 2 Voxel sich nicht am selben Platz befinden können? Und warum ist das nicht möglich?

    > > Es muss nicht alles mit allem interagieren. Alles bewegte muss mit der
    > > direkten Nachbarschaft interagieren. Klar wenn du aus dem Fenster guckst
    > > bewegt sich scheinbar alles. Man kann aber eine Virtuelle Realität
    > kreieren
    > > die zu 99,9% starr ist und trotzdem belebt wirkt.
    > > Warum ein Neuaufbau von Daten notwendig sein soll erschließt sich mir
    > > nicht, wenn es darum geht die Position von Atomen zu verändern.
    >
    > Klar erschliesst sich dir das nicht. Du offenbarst mehr und mehr dass du
    > nur mit Halbwissen argumentierst und scheinst viele Grundkonzepte nicht zu
    > kennen. Z.B. warum eine Veraenderung der Position eines Atoms den Octree
    > veraendert.

    Hier offenbart sich nur deine Arroganz. Ich weiß um Octrees. Ich selbst habe mindestens ein Dutzend implementiert. Du scheinst da aber was nicht verstanden zu haben, Zitat: "neuaufbau der datenstruktur". Oder willst du bei der Behauptung bleiben das das verschieben eines Voxels einen Neuaufbau des Octree erforderlich macht? Ist es nicht so das sich nur zwei Pfade ändern?
    Eigentlich habe ich gar keine Bock dich weiter aufzuklären, aber vielleicht kann man dich von deiner Arroganz heilen. Wenn ich den Baum immer vollständig aufgeklappt lasse, also leere Blätter nicht entferne und die Bewegung eines Voxels nur um eine Raumeinheit geschieht dann lässt sich das Procedere stark codetechnisch optimieren. Voxel wandern nur zu bekannten Nachbarn, liegen immer auf der untersten Ebene und bei den Elternknoten muss nur ein Zähler aktualisiert werden.

    > > > Einfaches Gegenbeispiel
    > > > waere hier ein Wald mit N Bauemen auf einer quadratischen Flaeche
    > > > platziert.Viele Strahlen schiessen komplett durch ohne einen Baum
    > > erwischt
    > > > zu haben und ein Teil ist ganz nah an O( sqrt(N) ) Bauemen. Die
    > muessen
    > > > jetzt alle aus der Hierarchie ausgepackt werden. Bedeutet, O( sqrt(N)
    > )
    > > >
    > > > O( log N) Aufwand und damit nicht logarithmisch. Man kann auch Faelle
    > > mit
    > > > O(N) konstruieren z.B. eine Allee.
    > >
    > > Schlicht blödsinn.
    > > Mit Octrees muss ich nur den allerkleinsten Teil auspacken.
    > > Und auspacken muss man nur wenn man komprimiert.
    > >
    >
    > Fuer Nicht-Grafiker ist das wohl zu kompliziert. Stell dir einen Strahl
    > vor, der ganz knapp an einer Reihe von Grashalmen(sagen wir M)
    > vorbeischiesst und nur den letzten Halm trifft. Du musst bei jedem
    > einzelnen Grashalm bis zur eigentlichen Geometrie runtersteigen um zu
    > erkennen, dass der Strahl den Halm nicht schneidet. Und dieses
    > runtersteigen und schnitttests durchfuehren kostet Aufwand, und das fuer
    > ALLE M grashalme.

    Für Nicht-Programmierer und Menschen mit beschränkten Horizont mag das so sein.
    Für kreative Programmierer ergeben sich deine Probleme nicht. Worin liegt das Problem einen Strahl nur ein Budget an Operationen zu vergeben? Bei deinem Beispiel bedeutet das nach dem z.b. 3 knappen Vorbeiflug abgebrochen wird und der knappste Vorbeiflug als Ergebnis zurückgeliefert wird. Das garantiert einen festen Zeitaufwand pro Strahl unabhängig von der Weltgröße und Beschaffenheit.
    Aber es ist dir wahrscheinlich nicht perfekt genug wenn man auf einen Strohballen guckt und nur die ersten 10 "Schichten" akkurat gerendert werden, was natürlich die Technik grundsätzlich in Frage stellt weil von zukünftiger zusätzlicher CPU-Power nicht auszugehen ist.

    > Dass du dieses Gegenbeispiel mit dem Octree-zaubert-das-weg Argument
    > wegwischen willst zeigt wieder dass du nur mit Halbwissen argumentierst.

    Hör auf dich aus dem Fenster zu lehnen. Ich seh dich schon abstürzen.

    > > > Pures Raytracing killt dich immer wieder durch die paar Strahlen die
    > > > geradeso durchhuschen und dabei ordentlich im speicher rumwuehlen.
    > >
    > > Du hast immer nur herkömmliches komplexes Raytracing im Kopf.
    > > Wir reden hier aber über Raytracing mit maximal 2/3 Primitiven in einem
    > > DISKRETEN Raum. Dann huscht da eben was durch wenn man nicht genug CPU
    > hat.
    > Schon wieder wird komplexitaet durch den 'diskreten' Raum weggezaubert.
    > Ohne LOD nuetzt dir die diskretisierung nix. Auch in sparse voxel
    > repraesentation kriegt man keinen logarithmischen Aufwand hin ohne LOD zu
    > verwenden.

    Die Diskretisierung bringt ne ganze Menge wie ich bereits ausgeführt habe, auch ohne LOD.

    > > Was genau meinst du mit im "im speicher rumwuehlen"?
    > Speicher an zufaelliger Addresse auslesen -> kein caching moeglich, killt
    > die performance.

    Nur wenn man glaubt das jeder Strahl akkurat sein muss.
    Nur wenn man glaubt das ein bis ins letzte Detail korrektes Ergebnis wichtiger ist als die Performance und dieses Dogma hochleben lässt um sich etwas neuem zu verschließen.

    >
    > > Wenn man momentan nur ein paar tausend Atome dynamisch verarbeiten kann,
    > > dann muss dafür sorgen das sich nicht mehr bewegen. Wenn man mit ein
    > paar
    > > tausend Atomen nichts anfangen kann sondern mindestens 100000 braucht
    > dann
    > > muss eben 99% starr sein. Dann ist eben 99% der Welt Fels. Ja Und?
    > Mit andern Worten: statische Welt die eigentlich keine Physik benoetigt
    > weil sich ja eh nix bewegt.

    Ja hättest du erst einmal weitergelesen. Aber ich merk schon. Du willst nur noch ko**en. Deswegen versuchst du nicht zu verstehen und kapierst zum Beispiel auch nicht das die Einschränkung auf ein paar tausend bewegte Atome nicht bedeutet das die Welt insgesamt wirklich starr sein muss. Es geht darum dafür zu sorgen das sich möglichst wenige Atome GLEICHZEITIG bewegen:
    - Eine Quelle spuckt erst dann ein neues Wasser-Atom wenn zuvor irgendwo eins "versunken" sprich entfernt wurde.
    - Wasseratome können riesig sein, was die Anzahl vermindert.
    - Ein Fels ist zu massiv als dieser durch irgendetwas anderes als Fels verändert werden kann.
    - Sand ist so massiv das keine einfachen Abdrücke entstehen, aber trotzdem leicht genug um auf andere Weise verändert zu werden.
    -Sei mal etwas kreativ und nicht so voreingenommen

    > Ich glaube dir sind die subtilen Unterschiede zwischen verschiedenen
    > Techniken nicht klar und kennst die grundlegenden Grenzen nicht, z.b. das
    > mehr RAM die Probleme nicht loest. Ich hab auch keine Lust da jetzt jeden
    > einzelnen Punkt weiter einzugehen weil du dir nichtmal die muehe machst den
    > raytracing worst case zu verstehen. Dir fehlt schlicht und einfach
    > Fachwissen um so eine Diskussion fuehren zu koennen.

    Ich glaube du bist voreingenommen und versuchst nicht zu verstehen was man dir sagt. Verständlich wenn man, Zitat, "keine Lust" hat und sich für unfehlbar & allwissend hält. Dann blaht man mal eben raus das sein Gegenüber sich keine Mühe gibt Punkt X zu verstehen. Man könnte es ja auch zivilisierter formulieren und die Antwort abwarten. So aber muss du erneut erst im Nachhinein feststellen wie überheblich du warst und das du anscheinend doch nicht alles weist.

    Zitat: "Fuer Nicht-Grafiker ist das wohl zu kompliziert"
    Du weißt schon das die Grafik eigentlich nur ein Randthema ist im Moment?
    Zitat: "Ich glaube dir sind die subtilen Unterschiede zwischen verschiedenen Techniken nicht klar"

    Ich habe nicht gesagt das mehr RAM grundsätzlich alle Probleme löst. Ich habe gesagt das langfristig das Verhältnis von benötigtem RAM zu CPU immer größer wird.
    Abgesehen davon hilft RAM ungemein wenn CPU knapp ist. Je mehr RAM ich habe, desto freundlicher kann ich abspeichern. Hätte man zu heutigen CPUs Terrabyte-RAM könnte man alle möglichen Add/Del-Operationen eines Octree-Leaf vorberechnen so das die eigentlich Operation nur noch ein Setzen von Referenzen wäre, zumindest auf unterster Ebene.



    1 mal bearbeitet, zuletzt am 16.08.12 02:26 durch teenriot.

  13. Re: Interaktion mit Objekten in Spielen

    Autor: GiveUsMcNeal! 16.08.12 - 04:02

    teenriot schrieb:
    --------------------------------------------------------------------------------

    > Für Nicht-Programmierer und Menschen mit beschränkten Horizont mag das so
    > sein.
    > Für kreative Programmierer ergeben sich deine Probleme nicht. Worin liegt
    > das Problem einen Strahl nur ein Budget an Operationen zu vergeben? Bei
    > deinem Beispiel bedeutet das nach dem z.b. 3 knappen Vorbeiflug abgebrochen
    > wird und der knappste Vorbeiflug als Ergebnis zurückgeliefert wird. Das
    > garantiert einen festen Zeitaufwand pro Strahl unabhängig von der Weltgröße
    > und Beschaffenheit.
    > Aber es ist dir wahrscheinlich nicht perfekt genug wenn man auf einen
    > Strohballen guckt und nur die ersten 10 "Schichten" akkurat gerendert
    > werden, was natürlich die Technik grundsätzlich in Frage stellt weil von
    > zukünftiger zusätzlicher CPU-Power nicht auszugehen ist.

    Wo wir wieder beim faken angekommen waeren. Das hat echt kein Zweck mit dir, du drehst alles immer so hin, wie dir das grade passt. Wie z.B. ein Atom darf auf einmal nur 1 Voxel weiterwandern... Aber immerhin scheint jetzt durchgedrungen zu sein, dass Raytracing nicht per se logarithmischen Aufwand hat. Ist ja schonmal was.

  14. Re:

    Autor: teenriot 16.08.12 - 04:25

    GiveUsMcNeal! schrieb:
    --------------------------------------------------------------------------------
    > teenriot schrieb:
    > ---------------------------------------------------------------------------
    > -----
    >
    > > Für Nicht-Programmierer und Menschen mit beschränkten Horizont mag das
    > so
    > > sein.
    > > Für kreative Programmierer ergeben sich deine Probleme nicht. Worin
    > liegt
    > > das Problem einen Strahl nur ein Budget an Operationen zu vergeben? Bei
    > > deinem Beispiel bedeutet das nach dem z.b. 3 knappen Vorbeiflug
    > abgebrochen
    > > wird und der knappste Vorbeiflug als Ergebnis zurückgeliefert wird. Das
    > > garantiert einen festen Zeitaufwand pro Strahl unabhängig von der
    > Weltgröße
    > > und Beschaffenheit.
    > > Aber es ist dir wahrscheinlich nicht perfekt genug wenn man auf einen
    > > Strohballen guckt und nur die ersten 10 "Schichten" akkurat gerendert
    > > werden, was natürlich die Technik grundsätzlich in Frage stellt weil von
    > > zukünftiger zusätzlicher CPU-Power nicht auszugehen ist.
    >
    > Wo wir wieder beim faken angekommen waeren.

    Beim graphischen Faken ja, wenn man deinen Wortschatz verwendet, wie bei herkömmlichen Engines auch alles gefaked ist und zwar physikalisch und graphisch.
    Dieses 'Faken' ist eigentlich nichts anderes als das lokal die Bildschirmauflösung reduziert wird. Ich schätze du nennst es auch Faken wenn man der Performance wegen auf einem HD Monitor eine Anwendung in 800x600 betreibt und die Bilder aus Rechtecken "zusammengefaked" werden.
    Deine Grafik-Egozentrik geht mir auf die Nerven. Das ist nicht das Thema.

    > Das hat echt kein Zweck mit dir, du drehst alles immer so hin,
    > wie dir das grade passt.

    Was du hindrehen nennst, nenne ich Lösung. Bei deiner Lösung, die gar keine ist weil diese nur Grafik behandelt, ist auch alles 'hingedreht'. Wie soll es auch anders gehen mit heutiger Technik.
    Man kann sich natürlich wie du hinstellen und alles ablehnen weil es nicht perfekt ist und jede Lösung ablehnen weile diese nicht allgemein genug, ein Speziallfall ist.
    Nur gebe es kein Polygon-Engines auf heutigen Niveau wenn es nach dir ginge und du 1997 mal einen Blick auf den stand der Dinge geworfen hast.

    > Wie z.B. ein Atom darf auf einmal nur 1 Voxel weiterwandern...

    Hast du es mal wieder unterlassen zu verstehen was ich sage?
    Bist du gerade zu aggro damit dir dein Expertenhirn verklickert das eine Bewegung von 7 Einheiten genausogut 7 mal eine Bewegung von einer Einheit ist?

    > Aber immerhin scheint jetzt durchgedrungen zu sein, dass Raytracing nicht per
    > se logarithmischen Aufwand hat. Ist ja schonmal was.

    Nun biste aus dem Fenster gefallen.
    Ich nie behauptet das Raytracing per se logarithmischen Aufwand hat. Ich habe gesagt das es nur mit Raytracing möglich ist logarithmischen Aufwand zu erreichen.
    Aber das sind ja dann Spezialfälle, die gelten nicht, richtig?



    5 mal bearbeitet, zuletzt am 16.08.12 04:39 durch teenriot.

  15. Re: Re:

    Autor: GiveUsMcNeal! 16.08.12 - 20:43

    > Ich nie behauptet das Raytracing per se logarithmischen Aufwand hat.
    > Du vergisst die Zeitkomplexität bei der ganzen Angelegenheit. Bei Raytracing ist die O(log N)

    Und ich falle aus dem Fenster? :-)
    Um logarithmischen Aufwand zu erreichen braucht man eine Szenenrepresentation, mit der man entferne Teile der Szene zusammenfassen kann. Ob du die nun raytraced oder per forwardmapping renderst ist komplexitaetstechnisch egal.
    Also Szenenrepresentation != Rendermethode.

    > In Zukunft wird es nur noch Raytracing/Raycasting geben weil es
    > nur mit diesen Techniken möglich ist mehr oder weniger unabhängig von der
    > Gesamtzahl der Atome ein Abbild zu erstellen.

    _nur_ mit diesen Techniken...
    aber ja, Grafik ist ja nicht das Thema, dann darfst du natuerlich so solche statements in den Raum stellen.

  16. Re: Re:

    Autor: teenriot 17.08.12 - 05:11

    GiveUsMcNeal! schrieb:
    --------------------------------------------------------------------------------
    > > Ich nie behauptet das Raytracing per se logarithmischen Aufwand hat.
    > > Du vergisst die Zeitkomplexität bei der ganzen Angelegenheit. Bei
    > Raytracing ist die O(log N)
    >
    > Und ich falle aus dem Fenster? :-)

    Du erkennst da keinen Unterschied in meiner Aussage und deiner Behauptung was ich gesagt habe? Nenne mir einen grafischen Polygon-Algorithmus der log N hat und werde diesen derart verhübschen das dieser nicht mehr log N ist. So argumentierst du gerade.
    Wenn du keine Angabe dazu findest ob ich vom worst oder best case rede dann nimmst du natürlich an das man vom worst case redet. Und dann ignorierst du natürlich alle Aussagen danach die einen anderen Eindruck erwecken.

    Man kann mit log N raytracen willst du das bestreiten? Offensichtlich nicht:

    > Um logarithmischen Aufwand zu erreichen braucht man eine
    > Szenenrepresentation, mit der man entferne Teile der Szene zusammenfassen
    > kann. Ob du die nun raytraced oder per forwardmapping renderst ist
    > komplexitaetstechnisch egal.

    > Also Szenenrepresentation != Rendermethode.
    Array != Constructor
    Ergibt genau so viel Sinn.


    > > In Zukunft wird es nur noch Raytracing/Raycasting geben weil es
    > > nur mit diesen Techniken möglich ist mehr oder weniger unabhängig von
    > der
    > > Gesamtzahl der Atome ein Abbild zu erstellen.
    >
    > _nur_ mit diesen Techniken...
    > aber ja, Grafik ist ja nicht das Thema, dann darfst du natuerlich so solche
    > statements in den Raum stellen.

    Ist dir das nicht peinlich?
    Der Threadersteller fragte nach Physik. Meine Antwort ging um Physik.
    Und jetzt zitierst du einen der zwei Sätze die kurz die Visualisierung behandelten um zu rechtfertigen das du fast ausschließlich über Grafik redest, nachdem ich schon sehr früh zu dir gesagt habe das es eigentlich um die Physik geht.

    Welche Botschaft willst du eigentlich versenden?

    Glaubst du es ist nicht möglich Atome mit newtonsche Physik zu verarbeiten?
    Glaubst du das wäre nicht perfekt realistisch?
    Glaubst du es ist keine grafische Darstellung möglich?
    Glaubst du es ist keine perfekte grafische Darstellung möglich?
    Glaubst du zu wissen wann welche Hardware zur Verfügung steht?

    Alles andere als Nein/irrelevant/Nein/irrelevant/Nein ist mMn pure Überheblichkeit.

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. über duerenhoff GmbH, Raum Stuttgart
  2. Meierhofer AG, München
  3. Radeberger Gruppe KG, Frankfurt am Main
  4. Deutsche Rentenversicherung Rheinland, Düsseldorf

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 17,99€
  2. 14,99€ (Bestpreis)


Haben wir etwas übersehen?

E-Mail an news@golem.de