Was kommt nach den Polygonen?

[skivi]

Wird es in naher Zukunft etwas anderes geben als Polygone wo noch effektiver sind und weniger Rechenleistung brauchen?

[tombman]

ich denk, daß ray tracing kommen könnte....

[mrdigital]

aha und wie werden bei Raytracing Objekte beschrieben?

[RLZ]

aha und wie werden bei Raytracing Objekte beschrieben?
Durch alles was mathematisch eine Schnittpunktberechnung zulässt.
Meistens aus Polygonen oder Freiformflächen.
Beliebt sind aber auch direkte Beschreibungen von Objekten wie Würfel, Kugel, Zylinder etc..
Raytracing für Spiele wird aber wohl länger auf sich warten lassen.
Mindestens bis die Grafikchips wirklich einen frei programmierbaren Teil haben, der auch effizient mit Fallunterscheidungen umgehen kann.
Dann würde sich eine recht geringe Transistorinvestition Raytracing vernünftig machen lassen.

[HellHorse]

Wobei raytracing ja nicht wirklich zu den besten globalen Beleutungmodellen gehört (Stichwort harte Schatten).
Für Reflektionen und Refraktionen ganz gut, aber sonst gibt es besseres.

[mrdigital]

Meine Frage ging eher dahin, dass Raytracing das Renderingverfahren darstellt, aber Poligone nichts mit dem verwendeten Renderingverfahren zu tun haben.

[Gast]

polygone sind doch schon effektiv genug,nur ihre anzahl wird noch immens steigen. die eigentlichen fortschritte werden aber sicherlich noch in der simulation von oberflächen/pixel shading liegen.

[san.salvador]

Ich will ein Spiel mit massig Voxeln (Outcast)!!

[up¦²]

Das nächste große Ding dürfde Displacement Mapping werden :rolleyes:

[DocEW]

polygone sind doch schon effektiv genug,nur ihre anzahl wird noch immens steigen. die eigentlichen fortschritte werden aber sicherlich noch in der simulation von oberflächen/pixel shading liegen.
Ich denke auch, daß nicht die Polygone als nächstes dran glauben müssen. Wenn heutzutage ein Computergeneriertes Bild unrealistisch aussieht, dann doch wohl fast nie wegen sichtbarer Ecken o.ä.. Und um wirklich irgendwie alles umzuschmeißen, hängt auch zuviel dran. Alle APIs verwenden nunmal Polygone, da müßte man ja alles vom GraKa-Treiber umrechnen lassen oder so... nee.

[micki]

das problem das ich bei polygonen sehe ist das immense datenaufkommen. 1million polys können schon auf 32MByte kommen. Da würde ich dann auch auf displacementmapping tippen in verbindung mit tesselierern. Statt dreiecken könnten dann auch leicht wieder Quads in mode kommen.

MfG
micki

[Muh-sagt-die-Kuh]

das problem das ich bei polygonen sehe ist das immense datenaufkommen. 1million polys können schon auf 32MByte kommen.Folgende Rechnung? 3 x 32 bit Float Werte für jedes Vertice, macht 12 byte pro Vertice und 36 byte pro Dreieck...dann kommt das hin, nur läuft das nicht so...

Man speichert keine einzelnen Dreiecke, man speichert Dreiecksnetze und spart selbst bei der einfachten Speicherung dieser als Strips schon alle redundanten Vertices ein. Die Topologie (die Verbindungen zwischen den Vertices) lässt sich auch auf diverse Arten effizient speichern, Valenzcodierung ist ein Beispiel, gleiches gilt für die Verticekoordinaten, hier kann man z.B. nur jedes n-te Vertice komplett abspeichern, alle darauf folgenden werden nur als int-Offset gespeichert. Das Datenaufkommen reduziert sich auf jeden Fall drastisch.Da würde ich dann auch auf displacementmapping tippen in verbindung mit tesselierern.Displacementmapping bringt auch Probleme mit sich, beispielsweise mit der Kollisionserkennung.Statt dreiecken könnten dann auch leicht wieder Quads in mode kommen.

MfG
mickiQuads? Eher weniger, die sind um einiges schwieriger handzuhaben als Dreiecke und bringen, meiner Meinung nach, keine wirklichen Vorteile.

[klumy]

Was bedeutet Displacement Mapping?

[micki]

Folgende Rechnung? 3 x 32 bit Float Werte für jedes Vertice, macht 12 byte pro Vertice und 36 byte pro Dreieck...dann kommt das hin, nur läuft das nicht so...
du hast heute meißt ca 1vertex/triangle im schnitt. deshalb kann man gleich mit verticen rechnen.

die haben einiges an daten,
xyz für position
xyz normale
xyz tangente
xyz bitangente/binormale
uv texturcoordinaten * anzahl davon
rgba vertexcolor
9 irradiance constanten....

aber egal was man an daten reinstopfen will, als entwickler mit hirn versucht man immer auf 16, 24, 32 oder 64 byte zu kommen, weil das allignment bei verticen sehr wichtig ist, da über indices meißt random im speicher rumgelesen wird. und random reads kosten noch mehr wenn sie unallignt passieren. deswegen ist das meißt benutze format heute 32byte

ob du da nun die xyz position in 3floats oder in einen 4byte color reinstopfst, das ist ziemlich egal, solange du auf 32byte kommst. es kann sein das du sogar die 4byte für die position benutzt um nicht auf 36byte zu kommen, dann wiederum 28byte hast und 4 dummybytes reinstopfst, weil du mit 28byte langsammer wärst als mit 32byte.

deswegen hab ich 32byte genommen.




zu qudas: wenn man nun ein quad tesseliert, dann schaut das sehr viel regelmässiger aus als das bei zwei dreiecken wäre (wenn man nicht gerade mit zweierpotenzen tesseliert).
bei einem quad kann man zudem noch jede kannte verschiedenhoch tesselieren, bei dreiecken könnte das ein wenig schwieriger sein wenn man keine T-errors bekommen möchte.
Ob man am ende die quads wieder in dreiecke zerteilt um sie zu zeichnen, oder ob man die quads so hoch tesseliert dass eh nur die vertices gezeichnet werden müssen um eine plane zu sehen, das ist dann dem hardwareherstellern zu überlassen.

MfG
micki

[micki]

Displacementmapping bringt auch Probleme mit sich, beispielsweise mit der Kollisionserkennung.

das ist wohl der grund weshalb um die nicht-eckigen-objekte in UT schon heutzutage kollisionsobjekte sind. darstellung und logic sollte grundsätzlich voneinander getrennt werden _wenn's_ _geht_ sonst gibt es immer probleme.

MfG
micki

[Muh-sagt-die-Kuh]

Was bedeutet Displacement Mapping?Eine Displacement-Map ist eine Textur, die ein Höhenfeld modelliert. Wendet man eine Displacement-Map nun auf ein flaches Quadrat an, so entstehen neue Dreiecke, die das Höhenfeld in der Displacement-Map nachbilden => ein echtes dreidimensionales Gebirge entsteht. Es ist ähnlich zu Bump-Mapping, nur dass eben nicht die Beleuchtung, sondern die Geometrie geändert wird.

[Coda]

Wobei raytracing ja nicht wirklich zu den besten globalen Beleutungmodellen gehört (Stichwort harte Schatten).
Photon Mapping.

zu qudas: wenn man nun ein quad tesseliert, dann schaut das sehr viel regelmässiger aus als das bei zwei dreiecken wäre (wenn man nicht gerade mit zweierpotenzen tesseliert).
Nein. Zwei Dreiecke die ein Quad ergeben, sehen exakt gleich aus.

das problem das ich bei polygonen sehe ist das immense datenaufkommen. 1million polys können schon auf 32MByte kommen. Da würde ich dann auch auf displacementmapping tippen in verbindung mit tesselierern. Statt dreiecken könnten dann auch leicht wieder Quads in mode kommen.
Du brauchst ja nicht immer die ganze Levelgeometrie im VRAM haben, ich kenne mindestens eine Engine, die das Zeuch in komprimierter Form im Hauptspeicher vorrätig hällt.

[RoKo]

Wobei raytracing ja nicht wirklich zu den besten globalen Beleutungmodellen gehört (Stichwort harte Schatten).
Öhm, wir haben doch zwei gebräuchliche Methoden, um eine 3D-Szene zu rendern:
-Die simple Rasterisierung, wie in Echtzeitanwendungen üblich
-Raytracing

Das globale Beleuchtungszeugs, dass dann die ganze diffuse Lichtausbreitung oder so berechnet, setzt doch auch auf diesen auf, oder?

Displacementmapping bringt auch Probleme mit sich, beispielsweise mit der Kollisionserkennung.
Ein Dreiecksnetz ist schlimmer. Das muss man dann zumindest in einen BSP-Baum oder so packen u.s.w.
Wenn man ein Gelände hat, das einfach über eine DisplacementMap definiert ist, ist es einfach. Kann nur sein, dass es etwas anders tesseliert wird, als die Kollissionsrechnung verläuft.
Andererseits wird überall behauptet, dass Kollissionen ein riesiges Problem bezüglich DisplacementMapping ist. Mach ich irgendeinen Denkfehler? Man muß doch nur die eigene x/y-Position auf die HeightMap übertragen und dann die Höhe vergleichen.

Nein. Zwei Dreiecke die ein Quad ergeben, sehen exakt gleich aus.
Nö, wenn Perspektivenkorrektur aus ist, sehen texturierte Quads besser aus. Sehr schön zu sehen, wenn man Playstation und Saturn vergleicht.
Gut, das ist jetzt nicht mehr so wirklich wichtig :D
Ich glaube, mit per Vertex Beleuchtung kann es auch etwas anders aussehen.

[betasilie]

Displacementmapping bringt auch Probleme mit sich, beispielsweise mit der Kollisionserkennung.Quads? Eher weniger, die sind um einiges schwieriger handzuhaben als Dreiecke und bringen, meiner Meinung nach, keine wirklichen Vorteile.
Wenn man DM "nur" an bzgl. der Kollisionsabfrage unkritischen Stellen nutzen würde, hätte man schon einen riesigen Schritt gemacht. ;)

[micki]

Nein. Zwei Dreiecke die ein Quad ergeben, sehen exakt gleich aus.
nein, das ist leider ein irrglaube. ein richtig rasterisiertes quad hat an jedem punkt die gewichtungen aller 4 ecken zu beachten, wodurch auch runde flächen entstehen können. das ist bei zwei dreiecken nicht der fall. selbst die texturierung kann sehr anders aussehen.

MfG
micki

[Gast]

Nch Polys kommen erstmal Voxel, das weiß doch jeder der .plan files ließt :-)

[Coda]

Sicherlich nicht.

nein, das ist leider ein irrglaube. ein richtig rasterisiertes quad hat an jedem punkt die gewichtungen aller 4 ecken zu beachten, wodurch auch runde flächen entstehen können. das ist bei zwei dreiecken nicht der fall. selbst die texturierung kann sehr anders aussehen.
Ein Quad ist flach, alles andere ist undefiniert.
Genau deshalb benützt man ja Tris, weil dort genau dieser undefinierte Fall nicht auftritt.

[RoKo]

Sicherlich nicht.


Ein Quad ist flach, alles andere ist undefiniert.
Genau deshalb benützt man ja Tris, weil dort genau dieser undefinierte Fall nicht auftritt.
Er meinte wohl eher die Beleuchtung des Quads, als die Form des Quads selber.

[Coda]

Na gut, da vielleicht, aber das Licht is heute eh Per-Pixel, von daher...

[micki]

Na gut, da vielleicht, aber das Licht is heute eh Per-Pixel, von daher...
von daher ist die interpolation trotzdem anders wenn du zwei Tris hast im vergleich zu einem richtig interpoliertem Quad.

und die Definition eines Quads ist nicht mehr und nicht weniger als dass es 4 Vertices hat.

MfG
mici

[Coda]

Jo, aber die Interpolation braucht man eher weniger heutzutage, zumindest nicht bei Sachen, die man sehen würde.

und die Definition eines Quads ist nicht mehr und nicht weniger als dass es 4 Vertices hat.
Quatsch. Es gibt in 3D nunmal die Möglichkeit das 4 Punkte nicht in einer Ebene liegen -> undefiniert.

[RoKo]

Jo, aber die Interpolation braucht man eher weniger heutzutage, zumindest nicht bei Sachen, die man sehen würde.
Quatsch, in 3D wird überall ruminterpoliert. Und selbst bei per-pixel-lighting werden immer noch die Normalen interpoliert.

[Coda]

Jo, aber da wirst du es nicht sehen können.

[micki]

Quatsch
kindisch


Es gibt in 3D nunmal die Möglichkeit das 4 Punkte nicht in einer Ebene liegen
mehr hab ich nicht geschrieben, ein 4punkte-poly ist ein quad, nicht mehr, nicht weniger.


-> undefiniert.
niemand sagt dass ein quad in einer ebene liegen müßte. jedes einigermassen gute cg-programm (max, maya,...) modelliert mit quads und die haben nirgens eine begrenzung auf eine ebene.


Jo, aber da wirst du es nicht sehen können.
den unterschied zwischen einem richtig interpoliertem quad und zwei tris kann man sehen, sowohl bei z, als auch bei texturen, normalen, colors...

MfG
micki

[Coda]

jedes einigermassen gute cg-programm (max, maya,...) modelliert mit quads und die haben nirgens eine begrenzung auf eine ebene.
Damit hast du dir selber ein Gegenargument vor die Füße gelegt.
Max rendert mit OpenGL, und die Grafikkarte kann garantiert nur Tris rendern, trotzdem funktioniert es.

[Mave@Work]

kindisch


mehr hab ich nicht geschrieben, ein 4punkte-poly ist ein quad, nicht mehr, nicht weniger.


niemand sagt dass ein quad in einer ebene liegen müßte. jedes einigermassen gute cg-programm (max, maya,...) modelliert mit quads und die haben nirgens eine begrenzung auf eine ebene.



MfG
micki

Ein 4-Punkte Poly ist ein Quad. Aber nicht alle möglichen 4 Punkte in 3D bilden ein Poly. Bei einem 4-Punkte Poly müssen diese in einer Ebene liegen ( Der 4te in einer Ebene mit den anderen drei !!)

Drei Punkte in 3D bilden immer!!! ein Polygon

[micki]

Damit hast du dir selber ein Gegenargument vor die Füße gelegt.
Max rendert mit OpenGL, und die Grafikkarte kann garantiert nur Tris rendern, trotzdem funktioniert es.
im viewport ist nur ein preview und das kann genauso fehlerhaft sein wie der alphablend, das heißt nicht dass es beim finalen rendern so fehlerhaft aussehen muss.

im anhang sind quads mit einer einfachen color-, uvset- und ppl-interpolation.
links das von mir vorgeschlagene verfahren, rechts das quad mit den zwei möglichen arten es zu tesselieren.

die quads sind auf einer plane (um deine definition von quads zu erfüllen).

MfG
micki

[Coda]

Es sieht so aus wie im finalen Render, soll ich nen Screenshot machen?

[Gast]

Hui hui in diesem Thread wird ja einiges durcheinandergebracht.

Polygone haben nichts mit dem Rendering selbst zu tun (also ist keine Frage des Raytracing usw.).

Polygone sind einfach eine Ausprägung der sogenannten B-Reps (Boundary Representation), die eine Variante des Modelling ist. Dabei wird einfach die Außenhülle eines Objektes in eine Datenstruktur gespeichert, und das repräsentiert das Objekt, daher boundary representation (außenhüllen-representation).

Andere Möglichkeiten des Modelling sind Blobs, Quadriken, Voxel, und andere. Grafikkarten heutzutage sind jedoch rein auf B-Reps ausgelegt (wenn man mal 3D-Texturen als eine Art "Voxel" ausnimmt).

Dabei sind nicht Triangles das derzeit effizienteste Primitiv, sondern ein naher Verwandter, die Triangle Strips.

Muß man für n Dreiecke bei einer Triangle List 3 * n Vertizes spezifizieren, so sind es bei Triangle Strips 2 + n Vertizes (vorrausgesetzt es lässt sich ein konsekutiver Strip finden, der die gesamte Triangle List repräsentiert). 2+n ist trivialerweise fast immer (also für alle Fälle bis auf endlich viele) weniger als 3*n.

Quads mögen eine gleichmäßigere Interpolation in manchen Fällen ermöglichen, sind aber dafür datenmäßig weniger effizient. Aber es gibt ja auch genauso QuadStrips. Wobei ich glaube, dass diese Interpolations"nachteile" bei der Tesselation eines Quads in 2 Dreiecke (wie das heute ja implizit geschieht) in allen Fällen vermeidbar ist.

Naja, jedenfalls hat die Repräsentation eines Objekts (also das sogenannte "Modelling", was als die Datenstruktur-Repräsentation eines Objekts definiert ist) herzlich wenig mit Raytracing oder traditionellem Rendering zu tun. Beides funktioniert mit so ziemlich allen Möglichkeiten der Objektrepräsentation in Datenstrukturen.

Jedenfalls glaub ich nicht, dass B-Reps, also Polygone (was ja dann Dreiecke, Quads, und andere Polygone einschließt, sowie curved Surfaces, die ja auch tesseliert werden und damit Polygone sind), in nächster Zeit von irgendwas anderem abgelöst werden. Zu groß sind die Vorteile von Vertex-basierten Primitiven (etwa in der Animation).

[Gast]

Übrigens, wenn ich mich nicht sehr irre, hat dieses Quad/Triangle Problem mit Perspective Texture Mapping zu tun, siehe:

http://www.cs.unc.edu/~andrewz/comp236/hw6/

sowie

http://www.cg.tuwien.ac.at/courses/Realtime/slides/06shading_rtr2003.pdf

[Benny12345]

Vielleicht wird irgendwann statt aus Polygone einfach alles aus einzelnen Pixeln zusammengesetzt....

[Coda]

Dabei sind nicht Triangles das derzeit effizienteste Primitiv, sondern ein naher Verwandter, die Triangle Strips.
Trotzdem werden nacher Tris gerendert, das is ja nur die Datenstruktur die sie repräsentiert.
Außerdem sind Trilists heutzutage gängiger (die Unreal Engine benützt z.B. nur Trilists)

[RoKo]

Wenn die Unreal-Engine wirklich nur Triangle-Lists benutzt, ist die Unreal-Engine wohl ziemlich deppert.
Wie kommst Du auf solch komische Ideen?

[Gast]

Vielleicht wird irgendwann statt aus Polygone einfach alles aus einzelnen Pixeln zusammengesetzt....

http://graphics.ethz.ch/main.php?Menu=3&Submenu=2

[micki]

Hui hui in diesem Thread wird ja einiges durcheinandergebracht.

Polygone haben nichts mit dem Rendering selbst zu tun (also ist keine Frage des Raytracing usw.).

Ja, ist nur ne beschreibungssprache für die geometrie, das problem was ich anspreche ist, dass graphiker meißt mit quads arbeiten aber am ende nur triangles dargestellt werden. das schaut manchmal schlecht aus, wenn man quads aber rekursiv tesselieren würde, könnte man eine sehr viel bessere darstellungsqualität erreichen (das wäre mein vorschlag für "was kommt nach den polygonen), nämlich polygone.


Übrigens, wenn ich mich nicht sehr irre, hat dieses Quad/Triangle Problem mit Perspective Texture Mapping zu tun, siehe:

http://www.cs.unc.edu/~andrewz/comp236/hw6/

sowie

http://www.cg.tuwien.ac.at/courses/Realtime/slides/06shading_rtr2003.pdf


leider irrst du dich doch. denn in meinem beispiel ist das quad absolut komplanar zur nearplane, es dürfte also keine perspektivische verzerrung entstehen. die verzerrung entsteht dadurch, dass die vertices kein linear zu interpolierendes uv-set haben. wenn man das quad in 2 tris aufteilt hat man andere pixel/texel verhältnisse .

klar lässt sich das problem abschwächen, aber mit 'richtig' interpolierten quads würde es sehr viel besser aussehen (auch auf terrain bezogen).

MfG
micki

[Coda]

Wenn die Unreal-Engine wirklich nur Triangle-Lists benutzt, ist die Unreal-Engine wohl ziemlich deppert.
Wie kommst Du auf solch komische Ideen?
flipcode.com hat Warren Marhsall gesagt.
Und das ist bei weitem nicht deppert, Trilists sind dank Vertex Cache min. genauso schnell und vereinfachen den Code. (ach ja, der Vertex Cache funktioniert sogar nur mit Trilists)

Wenn du's mir nicht glauben willst nimm D3D Spy und den DX9 Renderer...

[micki]

flipcode.com hat Warren Marhsall gesagt.
Und das ist bei weitem nicht deppert, Trilists sind dank Vertex Cache min. genauso schnell und vereinfachen den Code. (ach ja, der Vertex Cache funktioniert sogar nur mit Trilists)

Wenn du's mir nicht glauben willst nimm D3D Spy und den DX9 Renderer...

der vertexcache funktioniert bei indizierten vertexbuffern. egal ob list,fan,strip.

MfG
micki

[RoKo]

Wenn fast dreimal so große Indexbuffer nicht deppert sind, dann weiß ich auch nicht.
Und wie gesagt funktioniert der Buffer auch mit Strips.

[Xmas]

Wenn fast dreimal so große Indexbuffer nicht deppert sind, dann weiß ich auch nicht.
Und wie gesagt funktioniert der Buffer auch mit Strips.
Ein Index sind im schlechtesten Fall 4 Bytes, doch muss man bei Strips jeden Eckpunkt der zu mehr als 2 Dreiecken gehört doppelt speichern. Und das sind bei geschlossenen Objekten praktisch alle. Indizes und Strips schließen sich zum Glück gar nicht aus.

Der Vertexcache speichert bei einem Strip natürlich die letzten beiden Eckpunkte, aber nicht Eckpunkte zu denen man wieder zurückkehrt. Dafür braucht man Indizes.

[RoKo]

Ich hab eben ziemlich lange gebraucht, um das zu kapieren, da ich eigentlich immer davon ausgehe, dass man Indizes benutzt ;)

[Radeonator]

Quads? Nöö, glaub ich kaum. Überlegt mal simpel und logisch, dann wisst ihr auch wieso lieber Polygone benutzt werden. Poly heisst ja nun nicht zwingend Dreieck ;) Wobei ein Dreieck aufgrund seiner Form deutlich einfacher und "rundere" Formen als ein Quad darzustellen vermag...

[mrdigital]

Sorry Rad, aber das ist quark. Bei einem Quad ist es möglich, dass nicht mehr alle Eckpunkte in einer Ebene liegen, d.h. für eine eindeutige Beschreibung der von vier Punkten aufgespannten Fläche bräuchte man eine aufwendigere Mathematik als bei einem Dreieck. Aber dadurch ließen sich auch sehr "runde" Oberflächen gestalten. Dreiecke sind nur die geschickteste Vereinfachung, da hier 3 Punkte immer in einer Ebene liegen, somit die Beschreibung der Fläche immer eindeutig ist (unter der Annahme einer ebenen Fläche)

[Spasstiger]

Das Thema "Quads" klingt ja recht interessant. Gibt es eine Echtzeit-Grafikengine, die Quads verwendet?
Und sind heutige Grafikchips speziell auf die Verarbeitung von Dreiecken hin ausgelegt oder ließe sich ohne Performanceverlust auch das Rechnen mit Quads ermöglichen?
Wie wird denn bei einem Quad eigentlich der Farbwert jedes Pixels berechnet, wenn Gourad Shading zugrunde liegt? Hat sich da schon einer mit der Mathematik im Speziellen befasst? Bei Dreiecken erscheint mir Gourad Shading ja recht simpel, man muss ja nur die Punkte in einer Ebene bedenken. Aber woher weiß der Renderer, welche Punkte in die Quad-Fläche fallen?

[Radeonator]

Sorry Rad, aber das ist quark. Bei einem Quad ist es möglich, dass nicht mehr alle Eckpunkte in einer Ebene liegen, d.h. für eine eindeutige Beschreibung der von vier Punkten aufgespannten Fläche bräuchte man eine aufwendigere Mathematik als bei einem Dreieck. Aber dadurch ließen sich auch sehr "runde" Oberflächen gestalten. Dreiecke sind nur die geschickteste Vereinfachung, da hier 3 Punkte immer in einer Ebene liegen, somit die Beschreibung der Fläche immer eindeutig ist (unter der Annahme einer ebenen Fläche)


Was wäre denn wenn man quasi Polyform arbeiten würde? Also ganz gelöst von der Grundform. Mathematisch sicherlich nicht einfach aber machbar.

[mrdigital]

Das hängt davon ab, welchen Flächentyp man als einfachstes oder als Basismodell verwenden will. Im Moment sind das immer ebene Flächen, weil sich dies leicht mathematisch fassen und vor allem auch schnell in Hardware berechnen lässt. Man muss für fast alle Berechnungen nur lineare Gleichungen lösen (nur für die Distanz oder die Länge eines Vektors muss quadriert oder "wurzeliert" werden). Man muss also hauptsächlich multiplizieren und addieren. Das ist das, was die aktuellen 3D Karten im Prinzip sind, schnelle Multipizierer und Addierer (dafür bekomm ich Haue ;)) Alle anderen Flächenmodelle haben eben nicht mehr lineare Gleichungen sondern wenigstens quadratische Gleichungen als Beschreibungsgrundlage. Auf dem Papier kein so ernstes Problem, aber in Hardware eben wesentlich aufwendiger. Allerdings könnte man damit dann sehr schön organisch modellieren.

[Gast]

Zitat von mrdigital
aha und wie werden bei Raytracing Objekte beschrieben?

Durch alles was mathematisch eine Schnittpunktberechnung zulässt.
Meistens aus Polygonen oder Freiformflächen.
Beliebt sind aber auch direkte Beschreibungen von Objekten wie Würfel, Kugel, Zylinder etc..

Was aber auch noch geht sind Voxel, insbesondere bei Raytracing kann man
damit einen ernormen Geschwindigkeitsboost erleben.

Könnt ihr alles nachlesen in Alan Watt's Computergrafik Buch.

[Gast]

Vielleicht wird irgendwann statt aus Polygone einfach alles aus einzelnen Pixeln zusammengesetzt....

Wie soll das gehen?

Ein Pixel ist in einem 3d Raum ein Punkt und ein Punkt ist
mathematisch gesehen unendlich klein.
D.h. man kann mit ihnen nichts vernünftiges anfangen,
es gehen damit keine mehrfarbigen Flächen und auch keine Texturen.


Außerdem kann man in OpenGL einzelne Vertex schon als Punkte darstellen. GL_POINT aber wenn man damit eine Szene bildschirmfüllend erstellen will,
so daß es wirklich keine Lücken mehr auf dem Bildschirm gibt,
dann kann man auch gleich Polygone nehmen.

[aths]

Auf dem Papier kein so ernstes Problem, aber in Hardware eben wesentlich aufwendiger. Allerdings könnte man damit dann sehr schön organisch modellieren.Kann man auch mit Dreiecken, so sie klein genug sind. Das Dreieck ist als konvexes, planes Gebilde einfach ideal. Perspektivisch korrekte Interpolation ist afaik nicht linear, aber Freiformflächen würden alles sehr viel komplizierter machen.

[mrdigital]

Das hab ich doch nicht bestritten. Allerdings muss man, wenn man eine beliebige Fläche durch Dreiecke annähert doch sehr viele Dreiecke verwenden und irgendwann kommt der Punkt, ab dem sich das nicht mehr lohnt, wo also die Näherung durch Dreiecke (bei der sich zwar jedes einzelne Dreieck leicht berechnen lässt) mehr Rechenzeit benötigt als eine kompliziertere Beschreibung der Fläche (Bsp: 10000 Gitterpunkte werden benötigt, um eine Fläche in 100 * 100 Gitterpunkte zu zerlegen. Nun muss man also jedes mal 10000 Transformationen durchziehen um eine Fläche zu verändern. Pro Punkt sind es (nur für die Transformation der Geometrie, Beleuchtung und Texturierung mal aussen vor) 16 Multiplikationen und 12 Additionen. Also sind für diese Fläche 160000 Multiplikationen und 120000 Additionen fällig. Bei einem solchen Rechenaufwand kann man auch andere Beschreibungsmodelle wählen, aber wie gesagt, die Implementierung dieser in Hardware wäre schon aufwendiger.

[Coda]

MrDigital, schonmal nen Software Triangle Rasterizer geschrieben?
Dann würdest du das mit den Quads ganz schnell vergessen :rolleyes:

[aths]

Das hab ich doch nicht bestritten.Ja. Ich wollte es trotzdem noch mal bekräftigen.

Allerdings muss man, wenn man eine beliebige Fläche durch Dreiecke annähert doch sehr viele Dreiecke verwenden und irgendwann kommt der Punkt, ab dem sich das nicht mehr lohnt, wo also die Näherung durch Dreiecke (bei der sich zwar jedes einzelne Dreieck leicht berechnen lässt) mehr Rechenzeit benötigt als eine kompliziertere Beschreibung der Fläche (Bsp: 10000 Gitterpunkte werden benötigt, um eine Fläche in 100 * 100 Gitterpunkte zu zerlegen.Imo lohnt sich das immer. Lieber ein paar Stützpunkte transformieren als eine Freiformfläche mathematisch korrekt beschreiben.