Was für containers benützt ihr?
-
hellihjb schrieb:
Das ist schlecht zu vergleichen, denn O(log n) ist hier der Aufwand pro Strahl (bei einer Rekursionstiefe von 1 also der Aufwand pro Pixel) und damit wiederum abhaengig von der Aufloesung - der Pro-Pixel-Aufwand des Rasterizers ist primaer abhaengig vom Overdraw
Ja und der Overdraw/z-fail liegt in O(n); n == Anzahl der Polygone im viewing frustum. Insofern ist das schon richtig gewesen. Es kann ja O(n/10000) sein, aber eben O(n).
rapso schrieb:
klar kannst du noch culling in rasteriser einbauen, jedoch geht man laut der Rechnung von Prof.Dr. Milchmaenchen
davon aus, dass du beim rasterisieren jedes dreieck anfasst (sprich, in screenspace transformierst und rasterisierst bis dir der zbuffer sagt ob das ding zu sehen ist oder nicht).Ja es stimmt schon. Das eigentliche Zeichnen ist wirklich O(Anzahl Polygone im Viewing Frustum), beim Raytracer nicht notwendigerweise. Wahrscheinlich ist die Idee, dass je mehr Polygone im Frustum sind, desto mehr werden verdeckt.
btw. der Link zum Sonnenblumenfeld geht nicht
-
hellihjb schrieb:
Wieso hat ein Raytracer laut deiner Aussage eigentlich O(logn)?
Weil mit (statischen) Polygonen (n=poly) aufgrund der hierarchischen baume, die laufzeit logaritschmisch steigt.
Theoretisch ist also ein raytracer irgendwann schneller als ein rasterizer.Das ist schlecht zu vergleichen, denn O(log n) ist hier der Aufwand pro Strahl (bei einer Rekursionstiefe von 1 also der Aufwand pro Pixel) und damit wiederum abhaengig von der Aufloesung
diese Angabe bezieht sich auf den aufwand in relation zu der polygonzahl, fuer die aufloesung ist der aufwand O(n) (sofern man keine coherenzoptimierungen vornimmt)
- der Pro-Pixel-Aufwand des Rasterizers ist primaer abhaengig vom Overdraw
jein, bei extrem grossen polygonmengen zeichnen die meisten polys nichtmal einen pixel, der aufwand liegt dann constant pro poly das hinzukommt, also O(n). von diesem fall sprechen die Raytracing verfechter dann, denn logischerweise muss irgendwo ein raytracer mit O(log n) schneller sein als ein rasterizer mit O(n). natuerlich ist das ganze komplett praxisfern.
Daraus lernen wir also nur, dass bei einer Aufloesung von 1x1 Pixel ein hierarchischer Raytracer immer schneller ist...
das stimmt natuerlich auch
dass du beim rasterisieren jedes dreieck anfasst
Dann muss man fuer den Raytracer aber auch schon brute-force annehmen...
nicht zwingend. man kann schon konstelationen finden bei denen ein raytracer theoretisch schneller sein wuerde. wenn eben milliarden an blumen sichtbar vor dir sind. ein rasterizer mueste im stumpfen fall alle rasterisieren. ein raytracer wuerde sich nur die richtigen polys 'rauspicken'.
deren argumente sind faktisch nicht falsch, sie sind nur fuer bedingungen angegeben die in der realitaet niemand machen wuerde.
-
Ja und der Overdraw/z-fail liegt in O(n); n == Anzahl der Polygone
Zeig mal bitte, warum der Overdraw eines Rasterizers linear mit der Anzahl der Polygone steigt.
-
Optimizer schrieb:
btw. der Link zum Sonnenblumenfeld geht nicht
wieso nicht? 404 oder hotlink protection? bei mir geht's (tm)
vielleicht copy&paste http://blog.koehntopp.de/uploads/sunflowers.jpg
-
Hallo
Ich bekomme immer Fehler 403:
Forbidden
You don't have permission to access /uploads/sunflowers.jpg on this server.
chrische
-
Es war 403 aber mit c&p gings.
-
hellihjb schrieb:
Ja und der Overdraw/z-fail liegt in O(n); n == Anzahl der Polygone
Zeig mal bitte, warum der Overdraw eines Rasterizers linear mit der Anzahl der Polygone steigt.
Warum denn nicht? Es kann nur ein Polygon das vorderste sein
Stell dir einen 1x1 Pixel Bildschirm vor. Zeichnest du 100 Polygone im Frustum, hast du 100 z-Tests mit jeweils einem Overdraw/Fail. Zeichnest du 1000, hast du 1000...
Natürlich können sie bei einer höheren Auflösung auch nebeneinander liegen, aber das Sichtfeld wird ja nicht irgendwie immer weiter, je mehr Polygone es gibt (wir zeichnen wie gesagt die Polygone im Frustum). Das nebeneinander liegen macht also nur einen konstanten Faktor aus. Wo siehst du das Problem?
-
Stell dir einen 1x1 Pixel Bildschirm vor
In der Praxis steigt der Overdraw wenn die Flaeche eines zu zeichnenden Polygons unter einen Pixel faellt, also mehrere Polygone pro Pixel zu zeichnen sind.
In Deinem Spezialfall sind das natuerlich alle, denn es gibt nur ein Pixel - Dein Beispiel ist also nicht sonderlich praxistauglich und deckt sich mit meinem Antibeispiel:Daraus lernen wir also nur, dass bei einer Aufloesung von 1x1 Pixel ein hierarchischer Raytracer immer schneller ist...
-
Damit habe ich auch nur angefangen. Ich habe gezeigt, dass eine höhere Auflösung daran nichts ändert, außer einem konstanten Faktor. Wieviele Pixel ein Polygon einnimmt, ist außerdem egal. Eine höhere Auflösung bewirkt einfach nur, dass generell mehr Pixel zu zeichnen sind, aber das Verhältnis, welche Fläche wie oft überzeichnet wird, bleibt gleich.
Es zählen die Screenkoordinaten. Daran dass sie auf -1 bis 1 normalisiert sind, siehst du ja schon, wie egal die Auflösung ist.
-
rapso schrieb:
@xBlackKnightx wenn du denkst dass das hier komplett von dem abweicht was dich interresiert, sag bescheid und ich splitte es ab
nun, interessant ist es schon aber es ist für mich alles unbekannt und somit komplex
ich werd mit einfachen container wie list und vector anfangen und ein bißchen mit Zeitstempel experimentieren lassen, um rauszufinden wie schnell die sind.
Ist es auch ungewiss was für ein Containter der ObjektManager von Cinema4D benützt? Generell die ganzen 3D-Grafikprogramme. Die haben doch alle diese Objekt-Manager. Wenn man 3D-Objekte, Lichtquellen, Effekte usw hinzufügt sind sie alle in der Liste.
-
Wie gesagt, du musst zunächst einmal eine Anforderungsanalyse machen. Du musst dir genau überlegen, was wie oft auf diesen Containern ausgeführt wird. Zum Beispiel "in jedem Frame muss ich ends viele Objekte darin suchen" oder "in einer bestimmten Reihenfolge durchlaufen". Überlege dir auch, wie oft du Objekte hinzufügst und entfernst.
Wenn du das bestimmt hast, helfen wir dir gerne, den richtigen Container auszuwählen (oder eine Kombination davon). Auf andere Programme zu schauen nützt dir nichts, wenn sie nicht fast gleiche Anforderungen haben. Du musst etwas suchen, was für deinen Fall geeignet ist.
